Your message dated Wed, 03 Sep 2014 14:06:05 -0700
with message-id <[email protected]>
and subject line Re: weekly Samba/ldapsam failure serving files to a busy win2k
client
has caused the Debian Bug report #407516,
regarding weekly Samba/ldapsam failure serving files to a busy win2k client
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
407516: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407516
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libldap2
Version: 2.1.30-8
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.
However I can not get debian's samba maintainers to link against
libldap-2.3.0 because there is no -dev package, which I'm told is due to an
openssl licensing issue.
--- End Message ---
--- Begin Message ---
On 18/08/14 08:39 PM, Ryan Tandy wrote:
Since you wrote your report a lot has changed: OpenLDAP and Samba have
both received significant improvements, and today we have only a single
libldap version in Debian.
I noticed that the Samba bugs you filed have never been closed either,
so I'm wondering whether this was ever resolved for you, or whether you
eventually solved it on your own?
The email address used to submit the bug is no longer active, and I
wasn't able to find a current one. I don't see any way to move this bug
forward without feedback from the reporter, so I'm closing it. I'm
hopeful that bubulle's suggestion in the linked Samba bug, that this was
fixed by changes in Samba, is accurate.
--- End Message ---
