[Samba] Samba 3.2.7 server loses printer - driver assignment - aditional info

[Martijn Berger]

Jeremy Allison wrote:
> On Wed, Jan 21, 2009 at 09:54:03AM +0100, Remy Zandwijk wrote:
>   
>> OK, we have a backtrace (using dbx from Sun Studio):
>>
>>
>> /opt/SUNWspro/bin/dbx -I /var/tmp/source -S /opt/samba/sbin/smbd 24586
>> Reading smbd
>> Reading ld.so.1
>> Reading libthread.so.1
>> Reading libldap.so.5
>> Reading libcups.so.2
>> Reading libz.so.1
>> Reading libpthread.so.1
>> Reading libresolv.so.2
>> Reading libnsl.so.1
>> Reading libsocket.so.1
>> Reading libm.so.1
>> Reading libsec.so.1
>> Reading libsendfile.so.1
>> Reading libdl.so.1
>> Reading libtalloc.so.1
>> Reading libtdb.so.1
>> Reading libwbclient.so.0
>> Reading libc.so.1
>> Reading librt.so.1
>> Reading libmd5.so.1
>> Reading libmp.so.2
>> Reading libaio.so.1
>> Reading libc_psr.so.1
>> Reading UTF-16LE%CP850.so
>> Reading CP850%UTF-16LE.so
>> Reading nss_files.so.1
>> Reading nss_ldap.so.1
>> Reading libsldap.so.1
>> Reading libdoor.so.1
>> Attached to process 24586
>> t at 1 (l at 1) stopped in _waitid at 0xffffffff7d1a8788
>> 0xffffffff7d1a8788: _waitid+0x0008:     ta       %icc,0x0000000000000040
>> Current function is smb_panic (optimized)
>> dbx: warning: File `util.c' has been modified more recently than `smbd'
>>  1669                   result = system(cmd);
>> (dbx) where
>> current thread: t at 1
>>   [1] _waitid(0x0, 0x600b, 0xffffffff7fffee40, 0x103, 0x0, 0x0), at  
>> 0xffffffff7d1a8788
>>   [2] _libc_waitpid(0x600b, 0xffffffff7ffff000, 0x100, 
>> 0xfffffffffffffff8, 0x0, 0xffffffff7ffff071), at 0xffffffff7d1603a0
>>   [3] system(0x100862200, 0x100862200, 0x10060f770, 0x1, 0x684, 
>> 0x1007b43d0), at 0xffffffff7d19e744
>> =>[4] smb_panic(why = ???) (optimized), at 0x100318de4 (line ~1669) in "util.c"
>>   [5] cups_pcap_load_async(pfd = ???) (optimized), at 0x1002d26e4 (line 
>> ~393) in "print_cups.c"
>>   [6] cups_cache_reload() (optimized), at 0x1002d2e24 (line ~522) in  
>> "print_cups.c"
>>   [7] pcap_cache_reload() (optimized), at 0x1002d0e4c (line ~149) in "pcap.c"
>>   [8] reload_printers() (optimized), at 0x10058dbb8 (line ~799) in "server.c"
>>   [9] check_reload(t = ???) (optimized), at 0x100100b98 (line ~1887) in  
>> "process.c"
>>   [10] timeout_processing(select_timeout = ???, 
>> last_timeout_processing_time = ???) (optimized), at 0x100100c00 (line 
>> ~1908) in "process.c"
>>   [11] smbd_process() (optimized), at 0x1001010b0 (line ~2078) in "process.c"
>>   [12] main(argc = ???, argv = ???) (optimized), at 0x10058f180 (line 
>> ~1450) in "server.c"
>> (dbx)
>>
>>
>> From the logfile:
>>
>> [2009/01/21 08:57:01,  0] lib/util_tdb.c:(682)
>>   tdb(/var/opt/samba/locks/printing/st-compacta.tdb): tdb_reopen: file  
>> dev/inode has changed!
>>     
>
> Ok, you're hitting a strange panic I've only ever heard
> of on CentOS before.
>
> It's caused by too strict checking in the reinit_after_fork
> code. Here is the patch that has gone in for 3.2.8.
>
> Jeremy.
> -------------- next part --------------
> diff --git a/source/Makefile.in b/source/Makefile.in
> index 730e130..a4944b1 100644
> --- a/source/Makefile.in
> +++ b/source/Makefile.in
> @@ -693,7 +693,7 @@ NMBD_OBJ = $(NMBD_OBJ1) $(PARAM_OBJ) $(LIBSMB_OBJ) $(KRBCLIENT_OBJ) \
>  SWAT_OBJ1 = web/cgi.o web/diagnose.o web/startstop.o web/statuspage.o \
>             web/swat.o web/neg_lang.o
>  
> -SWAT_OBJ = $(SWAT_OBJ1) $(PARAM_OBJ) $(PRINTING_OBJ) $(LIBSMB_OBJ) \
> +SWAT_OBJ = $(SWAT_OBJ1) $(PARAM_OBJ) $(PRINTING_OBJ) $(PRINTBASE_OBJ) $(LIBSMB_OBJ) \
>  	   $(LOCKING_OBJ) $(PASSDB_OBJ) @LIBWBCLIENT_STATIC@ $(KRBCLIENT_OBJ) \
>  	   $(LIB_NONSMBD_OBJ) $(GROUPDB_OBJ) $(PLAINTEXT_AUTH_OBJ) \
>  	   $(POPT_LIB_OBJ) $(SMBLDAP_OBJ) $(RPC_PARSE_OBJ) $(LIBMSRPC_GEN_OBJ) $(LIBMSRPC_OBJ) \
> diff --git a/source/printing/print_cups.c b/source/printing/print_cups.c
> index 1bb149c..f3eb73c 100644
> --- a/source/printing/print_cups.c
> +++ b/source/printing/print_cups.c
> @@ -388,6 +388,8 @@ static bool cups_pcap_load_async(int *pfd)
>  	}
>  
>  	/* Child. */
> +	close_all_print_db();
> +
>  	if (!reinit_after_fork(smbd_messaging_context(), true)) {
>  		DEBUG(0,("cups_pcap_load_async: reinit_after_fork() failed\n"));
>  		smb_panic("cups_pcap_load_async: reinit_after_fork() failed");
>   
I got the same crash and then applied your patch.

commit 101ef64e3181335b66524296af08f7df04391b9a . The panics stopped, but we

I still have user who lose their printing settings/ driver assignment.
And if one loses it its a short while till people start reporting that 
they are unable to print.
 From what i can figure out its seems to relate to the amount of clients 
that are connected to the server.
I currently have 2 servers on the 3.2. (3.2.7 + the above patch). With 
one server that has about 35 clients at any time the drivers get unset 
about 2-3 times a day.
My second server that is in a now almost empty branch office has about 5 
clients and there the driver unset about once per 3 days.
The machines are almost identical and both run gentoo.

I hope this info helps.

-Martijn