Bug 3157 - Cups hangs on Samba3.0.20a with more than 160 Printershares
Summary: Cups hangs on Samba3.0.20a with more than 160 Printershares
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Printing (show other bugs)
Version: 3.0.20a
Hardware: Sparc Solaris
: P3 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-11 06:22 UTC by Bernhard Uhe
Modified: 2005-10-26 06:51 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Uhe 2005-10-11 06:22:29 UTC
I hat more than 160 Printershares on the Solaris-Samba-PDC. After update of 
Samba 3.0.20 / 3.0.20a cups hangs and the clients cannot print. The server is 
then very slow. With Samba 3.0.11 ist works fine.

Here the log.smbd entries.

2005/10/10 08:49:41, 0] printing/print_cups.c:cups_cache_reload(202)
  Unable to get printer list - server-error-service-unavailable
[2005/10/10 08:49:41, 0] printing/print_cups.c:cups_cache_reload(202)
  Unable to get printer list - server-error-service-unavailable
[2005/10/10 08:49:41, 0] printing/print_cups.c:cups_cache_reload(202)
  Unable to get printer list - server-error-service-unavailable
[2005/10/10 08:49:41, 1] smbd/service.c:close_cnum(835)
  pc101079 (172.25.101.79) closed connection to service abteil1
[2005/10/10 08:49:41, 0] printing/print_cups.c:cups_cache_reload(202)
  Unable to get printer list - server-error-service-unavailable
[2005/10/10 08:49:41, 0] printing/print_cups.c:cups_cache_reload(202)
  Unable to get printer list - server-error-service-unavailable
[2005/10/10 08:49:41, 0] rpc_server/srv_pipe.c:api_pipe_bind_req(981)

So i go back to version 3.0.11. What can I do.

Bernhard
Comment 1 Volker Lendecke 2005-10-11 06:51:46 UTC
One thing I found in a customer installation was that cups was simply too slow
to ship the list of printers to smbd via ipp. You might want to set

printcap name = /etc/printcap

and have cups explicitly write the current printcap file there.

Please tell us if this helps for you.

Thanks,

Volker
Comment 2 Bernhard Uhe 2005-10-14 02:42:53 UTC
Sorry, but with version 3.0.11 it works with no problems.
And with 3.0.20a not???

I can not test it with my productiv server.
Is that to 100 % correctly, that it's work with no problems?

Bernhard
Comment 3 Volker Lendecke 2005-10-14 03:22:27 UTC
100% is a strong one :-)

To be reasonably sure that this works correctly, a fallback is to create all
printer shares explicitly with a script. Then no printcap functionality is used
at all. If you find it working fine for test printers where you remove the
explicit entry again, you can then remove them all again.

BTW, setting up a little test enviroment would help for other experiments as
well :-)

Volker
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-10-26 06:51:36 UTC
The only major changes to how printers were cached was in 3.0.11.
But on change between 3.0.14a and 3.0.20 was that the 'printcap
cache time' option no defaults to 12 minutes.  (before smbd never tried 
to reload the printer name cache unless it received a SIGHUP.

So setting 'printcap cache time = 0' should restore the previous
behavior.

Marking as fixed.  You can reopen once you finally get a chance 
to test and if neither suggestion resolves the issue.