Bug 1443 - Samba 3.0.4 shows strange behaviour unter high load
Samba 3.0.4 shows strange behaviour unter high load
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.4
Sparc Solaris
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-08 08:19 UTC by Joerg Moellenkamp
Modified: 2005-08-24 10:21 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joerg Moellenkamp 2004-06-08 08:19:36 UTC
Samba 3.0.4 with recommendes patches on Solaris 8 (with increased settings for
filedescriptor).

System runs well under normal load. In peak hours (500-600 Clients) the
following message appears.

[2004/06/08 16:39:28, 0] lib/util.c:smb_panic2(1398)
  PANIC: internal error
[2004/06/08 16:39:28, 0] smbd/tdbutil.c:smbd_tdb_log(42)
  tdb(/usr/local/smb/xxxxx/locking.tdb): tdb_reopen: open failed (No such file
or directory)
[2004/06/08 16:39:28, 0] smbd/server.c:open_sockets_smbd(419)
  tdb_reopen_all failed.
[2004/06/08 16:39:28, 0] lib/util.c:smb_panic2(1398)
  PANIC: tdb_reopen_all failed.
[2004/06/08 16:39:28, 0] lib/fault.c:fault_report(36)
  ===============================================================
[2004/06/08 16:39:28, 0] lib/fault.c:fault_report(37)
  INTERNAL ERROR: Signal 6 in pid 10969 (3.0.4)
  Please read the appendix Bugs of the Samba HOWTO collection
[2004/06/08 16:39:28, 0] lib/fault.c:fault_report(39)
  ===============================================================
[2004/06/08 16:39:28, 0] lib/util.c:smb_panic2(1398)
  PANIC: internal error

As stated in the messages the logging.tdb disappears.

Login of new users is impossible. Users already logged in seems to be
unaffected, as long no new resource is mounted. After restart system works
without problems, after a short time, the same problem appears.
Comment 1 Volker Lendecke 2004-07-09 02:10:33 UTC
Just to add a comment: I've seen that as well, but I did not have the time
to track it down. The locking.tdb simply vanished. *VERY* weird.

This was a customer system and I was not sure that 
someone else on the system might have done it.

Volker Lendecke
Comment 2 Volker Lendecke 2004-07-16 01:23:31 UTC
This seems to be real. Just got another report. What on earth can just delete
the locking.tdb????

Volker
Comment 3 Volker Lendecke 2004-07-16 02:47:06 UTC
Just to make sure all information is collected here. We suspect that the unlink
of locking.tdb might have happened in smbd_tdb_log after a corruption. The calls
to smbd_tdb_log have been removed in svn (and 3.0.5.rc1), so this comes down to
a tdb corruption problem.

Volker
Comment 4 Joerg Moellenkamp 2004-07-16 05:32:03 UTC
i was able to repoduce the bug only one time: while executing ./smbstatus in
10-seconds-intervals, ./smbstatus told after a while, that locking.tdb is
corrupt one time, after this, smbstatus did not report locks at all.
Comment 5 Jeremy Allison 2004-07-16 12:55:24 UTC
On the advice of Volker I'm closing this one. During my work on deferred opens I
discovered a bug in the locking code that could cause memory overwrites and
corruption in the code that called the tdb writes to locking.tdb. This could
cause this bug. If this can be reproduced in 3.0.5preX or above then please re-open.
Jeremy.
Comment 6 Gerald (Jerry) Carter 2005-08-24 10:21:35 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.