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.
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.
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.
Does the "cups connection timeout" help to solve that problem?
Günther, what do you think about this patch?
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!
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.
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.
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.
See also bug #7994
yes, let's close this. Steve, if you think this is not yet working well in 3.6 please reopen the bug ... Thanks!