Red Hat Bugzilla – Bug 161952
cups command may output "service-error-service-unavailable" error message
Last modified: 2010-10-21 23:07:19 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2 Description of problem: cupsd calls ShutdownClient() function shutting off communication between a socket and a command. However, if the reply from a command is done earlier than the request of shutting off communication, cupsd may receive the reply first, causing the error message to be displayed. Version-Release number of selected component (if applicable): cups-1.1.17-13.3.27 How reproducible: Sometimes Steps to Reproduce: 1. Add a printer(s) as follows (50 - several 100) (See NOTE below) (a) lpadmin -p [PRINTER-NAME] -v [DEVICE-URI] -m [PPD-FILE-NAME] (b) accept [PRINTER-NAME] (c) enable [PRINTER-NAME] 2. Delete all the printers which were added in step #1. Carry out each command consecutively without an interval. (a) disable [PRINTER-NAME] (b) reject [PRINTER-NAME] (c) lpadmin -x [PRINTER-NAME] Repeat (1)-(3) and delete all printers. (d) lpadmin -p [PRINTER-NAME] -v [DEVICE-URI] -m [PPD-FILE-NAME] (e) accept [PRINTER-NAME] (f) enable [PRINTER-NAME] Repeat (4)-(6) and add all printers again. NOTE: Reproduction and reproduction frequency are dependent upon the load and performance of the hardware. Actual Results: A lpadmin/accept/enable/disable/reject command outputs "a server-error-service-unavailable" error message many times. Expected Results: A lpadmin/accept/enable/disable/reject command does not output an error message and succesfully executes. Additional info: kmori has backported the fix mentioned on the cups org site: http://www.cups.org/str.php?L434+P0+S0+C0+I0+E0+Qshutdown The fix was to use CloseClient() instead of ShutdownClient(), and it has been verified by customer solve this issue
Created attachment 116074 [details] Patch to use CloseClient() instead of ShutdownClient()
This was STR #434: http://www.cups.org/str.php?L434
*** Bug 161889 has been marked as a duplicate of this bug. ***
Red Hat Enterprise Linux 4 is not affected by this bug.
Nice to know that RHEL4 is not affected by this bug, but upgrading is not an option for us.
I have had this problem in combination with Samba. In the end, I did two things, but I don't know what it was that really made the difference. 1. Downgraded cups to the RPMs that were originally delivered with RHEL3U0. 2. Modified the printer name under which Samba makes it available. As for number 2, it's a longer story. I have a "load printers = yes" in smb.conf, so all my cups printers are shared via Samba. Initially they're shared under the queue name, but after you upload the Windows drivers from a Windows client to the print$ share, the share name that Samba uses all of a sudden becomes the name of the printer driver, in my case "Lexmark Optra S 1650 PS", which is 32 characters and that's longer than the 31 that smbd allows. I suspect that this is a bug in Samba which somehow makes its way into cups as well. Modifying the queue name on the Samba server, from a Windows client, back to the original queue name at least solved my problem. YMMV
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. http://rhn.redhat.com/errata/RHBA-2005-631.html
The resolution does not work for me. Therefor I would like to reopen this bug report.
Corne: please open a separate bug report. One bug has certainly been fixed as a result of this one, and it sounds like there is a separate bug that you have found with a very similar symptom.
I did open a seperate bug report a while ago. Bug 161889 Comment #14 From Tim Waugh (twaugh@redhat.com) on 2005-06-30 07:07 EST This has the same root cause as bug #161952. *** This bug has been marked as a duplicate of 161952 *** Could you please reopen that bug report.