[Pkg-samba-maint] Bug#407517: weekly Samba/ldapsam failure serving files to a busy win2k client

[Jamie ffolliott]

Package: samba
Version: 3.0.23d-2+b1

Kernel: 2.4.27-3-686-smp
Debian: etch (testing)
Hardware: 4-way Intel Xeon 550Mhz with 2GB RAM, mylex extremeraid 3000
controller.
(note: using kernel DAC960 driver, but mylex client software can only speak
to the driver in the 2.4 kernel)

Severity: should be critical, samba+ldap software fails in Etch in a simple
PDC configuration and LDAP backend, with filesharing to IIS.  Failure is
very consistent every 5-7 days depending on traffic.

Samba is setup with ldapsam backend, with the unix equivalent of an NT4
domain that previously worked in the same client/server configuration on
win2k fileservers.

I'm using slapd 2.3.30-2, however the ldap client libs are two openldap
generations older, at libldap2 2.1.30-8.  It's possible the bug is in
libldap2, however debian is dependent on this version due to licensing
issues in openssl that prevent a samba build against the libldap-2.3-0
package.

After one week, the smbd process for a busy client grows to 260MB of ram,
and near that point it begins to fail serving files, refuses new
connections, and eventually fails completely.  Other less busy windows
clients are served by separate smbd processes and have no issue.  The smbd
process in question needs a SIGKILL to kill it, it will not shut down
cleanly.  This Re-occurs every 5 to 7 days, causes downtime, and can't be
monitored remotely very easily due to the slow failure of smb connections
within the application that holds connections to the smbd process in
question.

The issue has been reported in detail to samba on Dec 4th in bugs,
https://bugzilla.samba.org/show_bug.cgi?id=4282
https://bugzilla.samba.org/show_bug.cgi?id=4297

You will find debug level 10 logs above.

At this point I've debugged kernel limits, potential openldap issues, and
samba issues.  It's clear to me that there's some sort of samba or ldap bug
that prevents an NT4 server from being replaced with samba.