Bug 5525 - samba locks up if cups server is unresponsive
samba locks up if cups server is unresponsive
Status: RESOLVED FIXED
Product: Samba 3.6
Classification: Unclassified
Component: Printing
unspecified
All Linux
: P3 enhancement
: ---
Assigned To: Björn Jacke
Samba QA Contact
http://bugs.debian.org/479512
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-08 01:44 UTC by Steve Langasek
Modified: 2011-09-05 08:33 UTC (History)
4 users (show)

See Also:


Attachments
patch to avoid talking to CUPS when not configured to load printers (646 bytes, patch)
2008-06-08 01:50 UTC, Steve Langasek
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Langasek 2008-06-08 01:44:41 UTC
If samba is configured for cups printing and the local cups printer is unresponsive, then smbd hangs even if 'load printers' is disabled.  This is because reload_printers() unconditionally reloads the printcap cache, even when there's no chance that this will result in printer shares being defined.

samba should be made more robust against problems with the cups server in cases where printers aren't even being exported by samba.
Comment 1 Steve Langasek 2008-06-08 01:50:39 UTC
Created attachment 3339 [details]
patch to avoid talking to CUPS when not configured to load printers

Here is a patch that I believe should prevent unnecessarily contacting the CUPS server when printers are not being shared.
Comment 2 Serge Bohdjalian 2008-12-05 10:12:57 UTC
With my system, Samba 3.0.28 AND 3.2.5 locked/hanged if CUPS was unresponsive. However, adding the following line to "smb.conf" prevented a lock/hang:

printcap = /etc/printcap

(My "printcap" file has only commented lines.) Even though there's a work around, presumably Samba should be more robust. While I believe CUPS support is usually present on Linux systems, this isn't the case on my VPS system. 
Comment 3 Karolin Seeger 2009-06-06 08:06:56 UTC
Does the "cups connection timeout" help to solve that problem?
Comment 4 Karolin Seeger 2009-06-06 08:07:32 UTC
Günther, what do you think about this patch?
Comment 5 Karolin Seeger 2009-06-06 08:23:04 UTC
This one has been fixed in 3.3.0 and newer with the "cups connection timeout (defaults to 60 seconds).

Closing out bug report.

Thanks for reporting!
Comment 6 Björn Jacke 2009-06-06 13:09:59 UTC
I like the idea that printer reloads are not being done when no printers are being used for sure. Currently printcap reload is being done by all client smbd processes; and via cups calls this is something which puts a cups server on high load. I'll reopen and assing this bug to myself to have a reminder to have a look at this.
Comment 7 Steve Langasek 2009-06-06 17:03:31 UTC
thanks, Björn; I agree, replacing an indefinite hang with a one-minute timeout isn't a very satisfactory fix for this, in cases that we know we're not supposed to be talking to the cups server anyway.
Comment 8 Andreas Schneider 2011-09-01 10:40:15 UTC
Björn, this bug is pretty old. CUPS updates are done in a forked child so that it doesn't block smbd in the meantime.

See cups_pcap_load_async() in printing/print_cups.c

In master we have a special process called background queue which is the only procsess doing pcap updates. This process forks also childs to do the CUPS updates. If the printcap cache has changed all processes are notified to reload the printer information.

I think we can close this bug.
Comment 9 Andreas Schneider 2011-09-01 10:40:53 UTC
See also bug #7994
Comment 10 Björn Jacke 2011-09-05 08:33:47 UTC
yes, let's close this. Steve, if you think this is not yet working well in 3.6 please reopen the bug ... Thanks!