While trying to get my mythbox root drive to spin down, I noticed that cups is frequently writing to, but not actually changing the contents of, the printcap file - every 30 seconds or so: [root@newbox ~]# while true; do date; dmesg -c | grep cups && md5sum /etc/printcap; sleep 5; done Fri Sep 14 09:26:05 CDT 2007 cupsd(21486): dirtied inode 100663445 (printcap) on dm-0 cupsd(21486): dirtied inode 100663445 (printcap) on dm-0 cupsd(21486): dirtied inode 100663445 (printcap) on dm-0 cupsd(21486): WRITE block 34472449 on dm-0 cupsd(21486): WRITE block 25879672 on dm-0 2f24f609ae1020ebcceec6e9d04e2aa5 /etc/printcap Fri Sep 14 09:26:10 CDT 2007 Fri Sep 14 09:26:15 CDT 2007 Fri Sep 14 09:26:20 CDT 2007 Fri Sep 14 09:26:25 CDT 2007 Fri Sep 14 09:26:30 CDT 2007 cupsd(21486): WRITE block 34472465 on dm-0 cupsd(21486): WRITE block 25879672 on dm-0 2f24f609ae1020ebcceec6e9d04e2aa5 /etc/printcap Fri Sep 14 09:26:35 CDT 2007 Fri Sep 14 09:26:40 CDT 2007 Fri Sep 14 09:26:45 CDT 2007 Fri Sep 14 09:26:50 CDT 2007 Fri Sep 14 09:26:55 CDT 2007 Fri Sep 14 09:27:00 CDT 2007 Fri Sep 14 09:27:05 CDT 2007 cupsd(21486): dirtied inode 100663445 (printcap) on dm-0 cupsd(21486): dirtied inode 100663445 (printcap) on dm-0 cupsd(21486): dirtied inode 100663445 (printcap) on dm-0 cupsd(21486): WRITE block 34472477 on dm-0 cupsd(21486): WRITE block 25879672 on dm-0 2f24f609ae1020ebcceec6e9d04e2aa5 /etc/printcap Fri Sep 14 09:27:10 CDT 2007 ... epoll_wait(1, {{EPOLLIN, {u32=3115452624, u64=25918000443033808}}}, 1024, -1) = 1 recvfrom(6, "9016 3 ipp://sandeen.net:631/pri"..., 1540, 0, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("10.0.0.100")}, [16]) = 127 time(NULL) = 1189780144 open("/etc/printcap", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 9 fcntl64(9, F_GETFD) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 write(9, "# This file was automatically ge"..., 182) = 182 I'm no cups wizard; should this be happening? It'll thwart attempts to idle the drive... If it's updating from the print server (I suppose that makes sense...) can it not rewrite if the info hasn't changed? Thanks, -Eric
Looks like it writes that file every time it processes browse data, without checking to see if it would cause any changes. Ought to be fixable.
Reported upstream.
Thanks Tim, I put myself on cc: upstream too :)
Could it be this simple? Index: cups-1.3.0/scheduler/dirsvc.c =================================================================== --- cups-1.3.0.orig/scheduler/dirsvc.c +++ cups-1.3.0/scheduler/dirsvc.c @@ -2140,10 +2140,11 @@ process_browse_data( process_implicit_classes(); /* - * Update the printcap file... + * Update the printcap file if changed... */ - cupsdWritePrintcap(); + if (update) + cupsdWritePrintcap(); } -Eric
not quite, I guess. Looks like new printers showing up cause it to get written, but vanishing printers do not. I guess I'll leave this one to the cups crew and go back to my ext3 bugs :) -Eric
Please try cups-1.3.1-2.fc8.
The 30s write is gone, great! If I add a new printer on my server and restart cups there, the client sees the change and writes a new printcap. However, if I remove that new printer on the server, and restart the server again, the entry remains in the client's printcap. Should it? Thanks, -Eric
The printcap should contain the same entries as 'lpstat -s' shows -- does it? Perhaps the client has not yet timed out the remote queue. You should not need to restart the server when adding or removing queues.
On the client: [root@newbox ~]# lpstat -s no system default destination device for lp: ipp://sandeen.net:631/printers/lp [root@newbox ~]# cat /etc/printcap # This file was automatically generated by cupsd(8) from the # /etc/cups/printers.conf file. All changes to this file # will be lost. lp|LaserJet 4L on sandeen.net:rm=newbox:rp=lp: lp2|LaserJet 4L on sandeen.net:rm=newbox:rp=lp2: and the server /etc/cups/printers.conf contains only "lp" - and has for at least an hour... server is running cups-1.1.22-0.rc1.9.20.2 FWIW
Think I see the problem. Please try 1.3.1-3.fc8 (building) -- add the queue back on the server, then verify that printcap is correct again, then remove the queue on the server. The printcap file should get re-written without that queue there.
Hm, ok. Now, I tried editing /etc/cups/printers.conf on the server to add lp2, and restarted the server. (not sure when I have to restart; figure it's harmless). The client is now seeing lp and lp2 both in lpstat and in /etc/printcap. Then I issued lpadmin -x lp2 on the server - client still sees both queues in lpstat and printcap. Restarted the server *grin* for good measure - client still sees both queues. Perhaps I should test this on the older cups before my feature request was addressed? -Eric
Please try cups-1.3.2-2.fc8 (building).
Ok, with the latest version, lpadmin -x lp2 on the server results in that queue disappearing on the client after about 5 mins... seems good to me! (I hope I waited long enough for the timeout on 1.3.2-1 ... I think I did) Thanks, -Eric
Great, thanks for testing.