| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Autobuild-User: Michael Adam <obnox@samba.org>
Autobuild-Date: Tue Mar 22 13:57:25 CET 2011 on sn-devel-104
|
| |
|
|
|
|
|
| |
print notify connection.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Fri Mar 18 21:34:30 CET 2011 on sn-devel-104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 7022554, smbds share a printcap cache (printer_list.tdb),
therefore ordering of events between smbd processes is important when
updating printcap cache information. Consider the following two process
example:
1) smbd1 receives HUP or printcap cache time expiry
2) smbd1 checks whether pcap needs refresh, it does
3) smbd1 marks pcap as refreshed
4) smbd1 forks child1 to obtain cups printer info
5) smbd2 receives HUP or printcap cache time expiry
6) smbd2 checks whether pcap needs refresh, it does not (due to step 3)
7) smbd2 reloads printer shares prior to child1 completion (stale pcap)
8) child1 completion, pcap cache (printer_list.tdb) is updated by smbd1
9) smbd1 reloads printer shares based on new pcap information
In this case both smbd1 and smbd2 are reliant on the pcap update
performed on child1 completion.
The prior commit "reload shares after pcap cache fill" ensures that
smbd1 only reloads printer shares following pcap update, however smbd2
continues to present shares based on stale pcap data.
This commit addresses the above problem by driving pcap cache and
printer share updates from the parent smbd process.
1) smbd0 (parent) receives a HUP or printcap cache time expiry
2) smbd0 forks child0 to obtain cups printer info
3) child0 completion, pcap cache (printer_list.tdb) is updated by smbd0
4) smbd0 reloads printer shares
5) smbd0 notifies child smbds of pcap update via message_send_all()
6) child smbds read fresh pcap data and reload printer shares
This architecture has the additional advantage that only a single
process (the parent smbd) requests printer information from the printcap
backend.
Use time_mono in housekeeping functions As suggested by Björn Jacke.
|
| |
|
|
| |
Guenther
|
| |
|
|
| |
Karolin
|
| | |
|
| |
|
|
|
|
|
|
| |
This fixes bug #6127.
Thanks to Justin T Pryzby <justinpryzby [at] users.sourceforge.net>
for the review!
Karolin
|
| |
|
|
| |
Signed-off-by: Andreas Schneider <anschneider@suse.de>
|
| |
|
|
| |
Jeremy.
|
| |
|
|
| |
Karolin
|
| |
|
|
|
|
|
|
|
|
| |
The default timeout for connections to CUPS servers is set
to 5 minutes in the CUPS libraries. The smbd hangs on startup
until the timeout is reached if the CUPS server is unreachable.
This parameter makes the timeout configurable. The default value
is set to 30 seconds.
Karolin
|
| |
|
|
|
| |
Karolin
(This used to be commit 9cde2525560536e16e2dbf991dbeb446260dd0df)
|
| |
|
|
|
| |
Karolin
(This used to be commit 5fa77c216bc43c3558aff3373f74554efdb9210d)
|
| |
|
|
| |
(This used to be commit 881eaa26e071a7fde9c6fc5eb42ae122d0ddd490)
|
|
|
tarball.
(This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14)
|
