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

[Jeremy Allison]

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");