Bug 290831 - cups rewrites (unchanged) printcap every 30s
cups rewrites (unchanged) printcap every 30s
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F8Target
  Show dependency treegraph
 
Reported: 2007-09-14 10:33 EDT by Eric Sandeen
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version: 1.3.2-2.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-24 07:18:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 2512 None None None Never

  None (edit)
Description Eric Sandeen 2007-09-14 10:33:09 EDT
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
Comment 1 Tim Waugh 2007-09-14 10:55:58 EDT
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.
Comment 2 Tim Waugh 2007-09-14 10:58:35 EDT
Reported upstream.
Comment 3 Eric Sandeen 2007-09-14 11:08:30 EDT
Thanks Tim, I put myself on cc: upstream too :)
Comment 4 Eric Sandeen 2007-09-14 11:26:13 EDT
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
Comment 5 Eric Sandeen 2007-09-14 12:00:38 EDT
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
Comment 6 Tim Waugh 2007-09-18 04:45:18 EDT
Please try cups-1.3.1-2.fc8.
Comment 7 Eric Sandeen 2007-09-18 08:49:52 EDT
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
Comment 8 Tim Waugh 2007-09-18 09:12:05 EDT
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.
Comment 9 Eric Sandeen 2007-09-18 11:11:58 EDT
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


Comment 10 Tim Waugh 2007-09-18 11:35:19 EDT
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.
Comment 11 Eric Sandeen 2007-09-18 12:11:48 EDT
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
Comment 12 Tim Waugh 2007-09-21 08:49:50 EDT
Please try cups-1.3.2-2.fc8 (building).
Comment 13 Eric Sandeen 2007-09-21 17:12:27 EDT
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
Comment 14 Tim Waugh 2007-09-24 07:18:27 EDT
Great, thanks for testing.

Note You need to log in before you can comment on or make changes to this bug.