Bug 132318

Summary: BrowsePoll fails after 5 minutes
Product: Red Hat Enterprise Linux 3 Reporter: Kevin Otte <kotte>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: imcguire, jdreese, mike.whitney, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:18:47 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:

Description Kevin Otte 2004-09-10 20:57:23 UTC
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 20:47:00 UTC
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 23:47:53 UTC
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 17:20:45 UTC
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 17:31:06 UTC
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 17:09:22 UTC
Kevin: could you possibly provide the full strace output?  Thanks.

Comment 6 Mike Whitney 2005-01-04 16:22:38 UTC
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 08:28:47 UTC
Mike: do you still see this problem?

Comment 12 RHEL Program Management 2007-10-19 19:18:47 UTC
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.