Bug 9650 - New or delete cups printerqueues are not recognized by the samba.
New or delete cups printerqueues are not recognized by the samba.
Status: RESOLVED FIXED
Product: Samba 3.6
Classification: Unclassified
Component: Printing
3.6.12
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-11 15:07 UTC by Franz Pförtsch
Modified: 2013-04-07 19:27 UTC (History)
2 users (show)

See Also:


Attachments
proposed fix for 3.6 (23.13 KB, patch)
2013-04-04 11:10 UTC, David Disseldorp
asn: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Franz Pförtsch 2013-02-11 15:07:34 UTC
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
Comment 1 David Disseldorp 2013-02-12 14:10:21 UTC
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.
Comment 2 Franz Pförtsch 2013-03-22 17:52:27 UTC
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
Comment 3 David Disseldorp 2013-03-22 18:12:14 UTC
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.
Comment 4 David Disseldorp 2013-03-22 18:16:55 UTC
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.
Comment 5 Franz Pförtsch 2013-03-24 17:02:18 UTC
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.
Comment 6 David Disseldorp 2013-04-04 11:10:54 UTC
Created attachment 8726 [details]
proposed fix for 3.6
Comment 7 Andreas Schneider 2013-04-04 13:25:15 UTC
Comment on attachment 8726 [details]
proposed fix for 3.6

LGTM.
Comment 8 David Disseldorp 2013-04-04 14:30:56 UTC
Thanks Andreas.
@Karolin, please push to 3.6-test. This bug does not affect samba 4.0.
Comment 9 Karolin Seeger 2013-04-07 19:27:23 UTC
Pushed to v3-6-test.
Closing out bug report.

Thanks!