New or delete cups printerqueues are not recognized by the samba. only when smbd is reloaded or restarted the printers are visible or gone. at smb.log the following messsages apears: Unlocking key 5052494E5445524C4953 [2013/02/08 17:57:48.896410, 3, pid=4103] printing/print_cups.c:445(cups_pcap_load_async) cups_pcap_load_async: already waiting for a refresh event I was waiting for hours. David Disseldorp <ddiss@suse.de> allready got the message. regards Franz
Looks like this is fallout from the shifting of printcap cache reload responsibility to the background queue process, done as a part of bug 9231. On startup the parent smbd process calls pcap_cache_reload(), which is done immediately before the background queue process is forked: 1237 /* Publish nt printers, this requires a working winreg pipe */ 1238 pcap_cache_reload(server_event_context(), smbd_messaging_context(), 1239 &reload_printers); 1240 1241 /* only start the background queue daemon if we are 1242 running as a daemon -- bad things will happen if 1243 smbd is launched via inetd and we fork a copy of 1244 ourselves here */ 1245 1246 if (is_daemon && !interactive 1247 && lp_parm_bool(-1, "smbd", "backgroundqueue", true)) { 1248 start_background_queue(smbd_event_context(), 1249 smbd_messaging_context()); 1250 } pcap_cache_reload() is asynchronous with cups, in that if forks a separate process to obtain the printer listing. The cache_fd_event print_cups.c global variable is used to track when a cups printer listing is in progress. cache_fd_event is set when the background queue process is forked, due to smbd's pcap_cache_reload() call immediately prior. As a result, the background queue process assumes an existing pcap_cache_reload() call is indefinitely outstanding.
Hello, what is happening after the "optimization" with the parameter "printcap cache time". I set it to a long time (750sec) does it make sence anymore? regards Franz
A proposed fix for the 3.6 branch can be found at: https://git.samba.org/?p=ddiss/samba.git;a=shortlog;h=refs/heads/bso9650_pcap_updates_broken_36t I'll forward port to master, and then post for review.
Hi Franz, (In reply to comment #2) > what is happening after the "optimization" with the parameter "printcap cache > time". Which optimization are you referring to? > I set it to a long time (750sec) does it make sence anymore? This is still a valid setting, "printcap cache time" corresponds to the time between polling the printing backend (e.g. cups) for the printer listing.
My question is because of the old processing. Befor the fix bug#9231, each smb process ask cupsd about the printers. So I decide to expand the "printcap cache time" to a high value, because of the high cpu-load After the fix only the one background process is asking cuspd. So I can decrease the value to something like 60 sec.
Created attachment 8726 [details] proposed fix for 3.6
Comment on attachment 8726 [details] proposed fix for 3.6 LGTM.
Thanks Andreas. @Karolin, please push to 3.6-test. This bug does not affect samba 4.0.
Pushed to v3-6-test. Closing out bug report. Thanks!