Bug 290831
| Summary: | cups rewrites (unchanged) printcap every 30s | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eric Sandeen <esandeen> |
| Component: | cups | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | Keywords: | Reopened |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.3.2-2.fc8 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-09-24 11:18:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 235704 | ||
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. |
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