We have a mechanism to detect and alert us when configuration files have been changed. We noticed that cupsd rewrites the /etc/cups/printers.conf file every time it starts: $ diff -U 3 printers.conf /etc/cups/printers.conf --- printers.conf 2010-02-15 16:31:39.551189687 -0500 +++ /etc/cups/printers.conf 2010-02-15 16:34:59.209137649 -0500 @@ -1,5 +1,5 @@ # Printer configuration file for CUPS v1.4.2 -# Written by cupsd on 2010-02-15 16:31 +# Written by cupsd on 2010-02-15 16:34 # DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING <DefaultPrinter Cups-PDF> Info Cups-PDF This is bogus. Daemons shouldn't arbitrarily rewrite their own configuration files. What seems to be happening is that cups is using printers.conf less as a configuration file, and more as a mechanism to save/restore state. If that's the case, then this file should be named /var/lib/cups/printers, not /etc/cups/printers.conf. Versions: 1:cups-1.4.2-20.fc12.x86_64
Marking as FutureFeature for consideration. It is a large change to make in terms of user expectation.
Perhaps. But since system-config-printer is the preferred administration mechanism, and http-based administration can also be used, I'm not sure that it matters that much. I suspect that users who are expert enough to be editing cups configuration files by hand are users who will be able to discover that the "config" files are in /var/lib/cups. And it is definitely wrong for a daemon to be maintaining state files in /etc, even if they are (mis)used as config files.
Could the timestamp updates be disabled, still permitting CUPS to rewrite the configuration file data if needed? This solves the immediate problem of CUPS upsetting auditing and fighting configuration management systems. This seems to be the solution that Debian opted for (no-conffile-timestamp.dpatch): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549673#29
Turning off the timestamp altogether seems wrong -- CUPS *will* rewrite that file when its configuration is changed via IPP, so we may as well know when that happened. I could see about removing the need to re-write the file on start-up though, if that's still happening; i.e. avoiding unnecessary re-writes of the file.
Change from comment #4 filed upstream.
Fix will be in 1.4.7.