Red Hat Bugzilla – Bug 142320
eggcups polls cupsServer() every 5 seconds
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Description of problem:
The eggcups process of desktop-printing creates a new log entry on the
cups server every 5s. (The eggcups process runs on the client system.
Connectins are made to the CUPS server, and log entries are on the
Excerpt from /var/log/cups/access_log
220.127.116.11 - - [07/Dec/2004:12:07:15 -0800] "POST / HTTP/1.1" 200 222
18.104.22.168 - - [07/Dec/2004:12:07:20 -0800] "POST / HTTP/1.1" 200 222
22.214.171.124 - - [07/Dec/2004:12:07:25 -0800] "POST / HTTP/1.1" 200 222
126.96.36.199 - - [07/Dec/2004:12:07:30 -0800] "POST / HTTP/1.1" 200 222
188.8.131.52 - - [07/Dec/2004:12:07:35 -0800] "POST / HTTP/1.1" 200 222
184.108.40.206 - - [07/Dec/2004:12:07:40 -0800] "POST / HTTP/1.1" 200 222
220.127.116.11 - - [07/Dec/2004:12:07:45 -0800] "POST / HTTP/1.1" 200 222
18.104.22.168 - - [07/Dec/2004:12:07:50 -0800] "POST / HTTP/1.1" 200 222
22.214.171.124 - - [07/Dec/2004:12:07:55 -0800] "POST / HTTP/1.1" 200 222
126.96.36.199 - - [07/Dec/2004:12:08:00 -0800] "POST / HTTP/1.1" 200 222
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install RedHat Enterprise linux WS with graphical interface
2.Desktop-printing will be installed with eggcups running
Actual Results: Log entries show up on CUPS server with connections
Expected Results: Connections should only be made once; there should
not be a new connection every 5s.
Does your client configuration vary from the RHEL default? In
particular I believe the default is to use a local server on the
client which just forwards jobs to a remote server; have you changed this?
Ok, one thing that confused me at first was that this bug was filed
against RHEL3, but the supplied package version is from RHEL4.
Sandra, can you confirm that this is fixed in desktop-printing-0.17-3?
*** This bug has been marked as a duplicate of 140536 ***
I am actually using RHE 3.
# cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 3)
I did make a mistake when conveying the version of desktop-printing.
We have been seeing this problem on a large number of systems running
RHE 3 or RH 9.0.
Sandra: Can you clarify whether the polling is occurring on the CUPS
server running on each client, or on a central CUPS server?
Tim: Any thoughts on this? From a glance at the RHEL-3 source, it
looks like it includes the initial dbus patch, but it's not used
since dbus is not included in RHEL3?
Sandra: Incidentally this program has been completely rearchitected
for RHEL4 - it now tracks individual user jobs and does not poll when
there are no active jobs for the current user. If you have a chance
to try the RHEL4 beta and confirm it works in your scenario, that
would be helpful.
Colin: you're correct. The dbus patch is not applied because dbus is
not available in Red Hat Enterprise Linux 3.
The central cups server is being polled, by clients running eggcups.
The cups server and the clients are physically different systems.
I'll try to look at RHE4
I'm afraid that for RHEL3 at the moment I can only offer the
workaround of removing eggcups from the user session (e.g. with
gnome-session-remove eggcups, followed by gnome-session-save). You
can also edit the default /usr/share/gnome/default.session for new
As I've said we've fixed this as part of a larger rearchitecting of
the code in RHEL4, but backporting the work would be difficult. I
hope that the workaround for RHEL3 will suffice until RHEL4 is released.
When we chose to purchase RHEL3 we were told that it would be patched
and updated, so that we would not be required to install a new OS
every year. This being the advantage of RHE over Fedora. That is
turning out to not be the case. This bug really ought to be fixed in
Sandra, it can potentially be fixed in RHEL3 but it's important to go
through support channels for this so it can be evaluated and placed on
the roadmap if appropriate using our established process.
https://www.redhat.com/apps/support/ is the right link to get started
bugzilla has no guaranteed response times or anything of that nature,
plus our developers are generally less able to help with questions
than the support team would be.
I would recommend referring to this bugzilla number in any support
requests, so we can keep track of the information that's already
been discussed here.
Sandra: Is the primary complaint here the network traffic itself, or
merely its symptoms such as the log files? If the latter, another
workaround is to lower the cups log level, e.g. with:
Personally I never felt the default CUPS log level was very useful.
Sandra, any thoughts on comment #11?
The complaint is both network traffic and the size of logs/ loss of
log data due to huge log files. (With increasing number of hosts
putting in logs every 5s, even with large log file limits it's
difficult to get this done.) We have been running on LogLevel info.
Will try warn.
Setting the LogLevel to warn does not prevent logging of the eggcups
connections. Setting the log level to error does. This is not a very
satisfying solution as logging of warning messages can be important.
Scratch that. I spoke too soon. Setting the LogLevel to error does
not prevent cups from logging the connections from eggcups. (I didn't
wait long enough after making the changes to check the log files.)
The next level is to set the LogLevel to off, which is less acceptable.
Sandra, I apologize: my initial suggestion for changing LogLevel was incorrect.
The LogLevel option only controls the output for /var/log/cups/error_log, not
/var/log/cups/access_log (which is where the eggcups accesses are being logged).
I would suggest this:
Incidentally RHEL4 is out now; I believe your subscription should allow
upgrading should you choose to do so.
Found that setting AccessLog to /dev/null resulted in permissions being changed
on /dev/null when cupsd started ... not especially good! Also have tried just
having AccessLog on a line by itself - seems to cause cupsd to die. Will try
setting the MaxLogSize to something managable. [RHEL AS rel 3 Taroon Update 5]
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.