Bug 142320 - eggcups polls cupsServer() every 5 seconds
eggcups polls cupsServer() every 5 seconds
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
Blocks: 156320
  Show dependency treegraph
Reported: 2004-12-08 17:33 EST by Sandra Wittenbrock
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2005-631
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 12:56:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sandra Wittenbrock 2004-12-08 17:33:45 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 - - [07/Dec/2004:12:07:15 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:20 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:25 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:30 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:35 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:40 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:45 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:50 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:07:55 -0800] "POST / HTTP/1.1" 200 222 - - [07/Dec/2004:12:08:00 -0800] "POST / HTTP/1.1" 200 222

Version-Release number of selected component (if applicable):

How reproducible:

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
every 5s.

Expected Results:  Connections should only be made once; there should
not be a new connection every 5s.

Additional info:
Comment 1 Colin Walters 2004-12-08 18:38:40 EST
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?
Comment 2 Colin Walters 2004-12-10 14:18:19 EST
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 ***
Comment 3 Sandra Wittenbrock 2004-12-10 19:48:57 EST
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.  
Comment 4 Colin Walters 2004-12-13 14:20:51 EST
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.
Comment 5 Tim Waugh 2004-12-13 17:42:43 EST
Colin: you're correct.  The dbus patch is not applied because dbus is
not available in Red Hat Enterprise Linux 3.
Comment 6 Sandra Wittenbrock 2004-12-13 19:13:24 EST
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
Comment 7 Colin Walters 2004-12-14 12:56:40 EST
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.
Comment 8 Sandra Wittenbrock 2004-12-16 13:16:38 EST
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
Comment 9 Havoc Pennington 2004-12-16 18:31:03 EST
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
I believe.

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.

Comment 11 Colin Walters 2004-12-16 18:46:50 EST
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:

LogLevel warn

Personally I never felt the default CUPS log level was very useful.  
Comment 12 Colin Walters 2005-01-03 15:32:17 EST
Sandra, any thoughts on comment #11?
Comment 13 Sandra Wittenbrock 2005-01-19 16:10:38 EST
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.
Comment 14 Sandra Wittenbrock 2005-01-21 17:08:48 EST
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.
Comment 15 Sandra Wittenbrock 2005-01-21 17:13:22 EST
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.  
Comment 17 Colin Walters 2005-02-24 10:47:26 EST
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:

AccessLog /dev/null

Incidentally RHEL4 is out now; I believe your subscription should allow
upgrading should you choose to do so.
Comment 24 Ed Tinnel 2005-07-28 09:00:15 EDT
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]
Comment 25 Red Hat Bugzilla 2005-09-28 12:56:56 EDT
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.


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