Bug 132318 - BrowsePoll fails after 5 minutes
BrowsePoll fails after 5 minutes
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-10 16:57 EDT by Kevin Otte
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:18:47 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)

  None (edit)
Description Kevin Otte 2004-09-10 16:57:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040803

Description of problem:
After being active for 5 minutes, the list of printers retrieved via
the BrowsePoll directive all time out.

The polling daemon has been spawned as:
cups-polld 172.16.52.115 631 30 631

According to the documentation, the cups-polld should be providing
updates to the local cupsd by broadcasting them to 127.0.0.1:631. 
Watching traffic to localhost with tcpdump reveals that the initial
retrieval of the printers is sent this way, but no further traffic is
ever seen.


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

How reproducible:
Always

Steps to Reproduce:
1. Add a BrowsePoll directive to /etc/cupsd/cupsd.conf
2. Restart cupsd
3. Monitor the printer list
    

Actual Results:  After 5 minutes, all printers disappear

Expected Results:  All printers should remain present while cupsd is
running.

Additional info:
Comment 1 Kevin Otte 2004-09-13 16:47:00 EDT
an strace -p against the cups-polld process indicates that when it is
done retrieving the printer list, it goes into a
nanosleep({2147483647,0},...), or a 68 year wait, as opposed to the 30
second wait it is supposed to go into.
Comment 2 Ian McGuire 2004-10-30 19:47:53 EDT
The problem also exists in cups-1.1.17-13.3.13.  The problem manifests
itself when BrowseInterval < number_of_printers.
Comment 3 Kevin Krafthefer 2004-11-22 12:20:45 EST
Norm is looking at this but he needs the broken cups.conf and the
mechanism being used to monitor the printer list?  (he is using printtool)
Comment 4 Kevin Otte 2004-11-22 12:31:06 EST
The cups.conf is unmodified from its packaged state.  I am just using
an lpstat -a and also tail -f'ing the contents of /var/log/cups/error_log.
Comment 5 Tim Waugh 2004-12-03 12:09:22 EST
Kevin: could you possibly provide the full strace output?  Thanks.
Comment 6 Mike Whitney 2005-01-04 11:22:38 EST
I have stumbled over this problem on our systems as well.  We are
currently using the workaround of increasing BrowseInterval to be
greater than the number of printers discovered on thet browse source.

As a useful debugging tip, you can kick the cups-polld out of its 68
year wait by sending it a SIGSTOP followed by a SIGCONT.  I can get an
strace of a full poll cycle this way, but haven't figured out how to
strace from the beginning when it's fired off from cupsd.
Comment 10 Tim Waugh 2005-09-09 04:28:47 EDT
Mike: do you still see this problem?
Comment 12 RHEL Product and Program Management 2007-10-19 15:18:47 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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