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:
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.
The problem also exists in cups-1.1.17-13.3.13. The problem manifests itself when BrowseInterval < number_of_printers.
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)
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.
Kevin: could you possibly provide the full strace output? Thanks.
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.
Mike: do you still see this problem?
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.