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):
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.
kmori has backported the fix mentioned on the cups org site:
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.
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.
The resolution does not work for me. Therefor I would like to reopen this bug
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.
Comment #14 From Tim Waugh (email@example.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.