Bug 370 - Garbage in locking database after 7..10 days of uptime
Summary: Garbage in locking database after 7..10 days of uptime
Alias: None
Product: Samba 2.2
Classification: Unclassified
Component: File Services (show other bugs)
Version: 2.2.8a
Hardware: All Linux
: P3 major
Target Milestone: ---
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
Depends on:
Reported: 2003-08-29 07:07 UTC by Alexey Lobanov
Modified: 2005-11-14 09:25 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Lobanov 2003-08-29 07:07:35 UTC
Linux Debian 3.01, Samba 2.2.8a self-compiled, kernel 2.4.21 self-compiled.

After 1..2 weeks of normal operation the first symptoma of upcoming crash are
bogus records in "smbstatus" output: non-existent (actually, already finished
without error) smbd process keeps a file with random unreadable 8-bit "name". In
1..2 days the anmount of such lines increase. Then, regular client application
failures. Samba restart with locking.tdb deletion does not help; problem returns
in 1 day. Linux restart helps, for same 1..2 weeks.

Maximal number of (true) smbstatus records during normal operation is like 800
total, 300 per client. Just Clipper and MS-Access-driven accounting.

Replaced: all hardware (motherboard, power, memory, HDD for /var), kernel 2.4.19
to 2.4.21, kernel SMP to single, Sambe 2.2.7 to 2.2.8a. The problem persists.

Non-standard features: ACL kernel patch, ACL in Samba, and ACL attributes at
ext2. Required.

Seems to help for the price of significant databases performance downgrade: "use
mmap = no". Not sure, because of insufficient test duration (3 weeks). maybe, it
just delays the crash.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-02-17 08:55:53 UTC
Sorry, but the 2.2 is not under development any longer.
If you can reproduce this bug against the latest 3.0 release, 
please reopen this bug and change the version in the report.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:25:03 UTC
database cleanup