Package: cupsys Version: 1.2.7-4 An innovation of CUPS 1.2 is Remote Printer Caching: cupsd saves the list of remote printers to /var/cache/cups/remote.cache on exit, and reloads it on start-up.
I've just become keenly aware of this feature following an incident which resulted in the remote.cache perpetuating an undesirable queue state across cupsd restarts; I ended up having to invoke-rc.d cupsys stop; rm /var/cache/cups/remote.cache; invoke-rc.d cupsys start on all my etch hosts to restore sanity. I have two IPP servers on my network (let's call them ipp1 and ipp2), advertising exactly the same queues to clients. My users and I rely on the implicit class mechanism, so "lp -d queue" will send the job to either [EMAIL PROTECTED] or [EMAIL PROTECTED] without the user having to be aware of the details. These servers happen to still be running Debian sarge (CUPS 1.1), but I don't think that's too important for the issue at hand. The clients have a couple of BrowsePoll lines in their cupsd.conf files, pointing to ipp1 and ipp2. A few days ago, ipp2 crashed (hardware failure, unrelated to CUPS). The Debian "etch" clients reacted by losing the implicit classes and only showing the [EMAIL PROTECTED] queues (incidentally annoying my users, who found that the usual queue names no longer worked; so that loss of the implicit classes should itself be regarded as a bug. I'll probably add a third IPP server to keep this from happening again.) After ipp2 was restarted, those clients started showing *both* the unqualified queue names and the [EMAIL PROTECTED] names. Unfortunately for redundancy, the unqualified queue names were no longer implicit classes, but pointed to ipp2 only. Restarting cupsd on these clients didn't cure the problem, which is how I found out (somewhat laboriously, by reading the source code) about the remote.cache feature. There is probably room for argument about what exactly needs to be fixed and how. Tentatively, I'll suggest that: 1) something went wrong when ipp2 was restarted and its queues were rediscovered by the clients: they should have received names with an explicit @ipp2 suffix, keeping the unqualified names for the implicit classes; 2) implicit classes shouldn't disappear when all but one of the instances go offline, as they now do; 3) the existence of the remote.cache file needs to be documented more prominently, so that administrators will know to check it (and perhaps remove it, as I've done) when troubleshooting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
