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...@1 (l...@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...@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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
