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

[Jamie ffolliott]

Hi Andrew,

I'll work on getting a valgrind log during off-hours and get back to you.

For now I've got some pool-usage output after the daemon's been running
almost 24hrs since last restart.  After the number of failures we've been
through now, it's hard to convince others here to allow samba to run long
enough to hit another failure.  But the memory does steadily increase, and
it's when it reaches around 260MB that it will consistently begin to fail.

I noticed most of the structures in there are this one:
        struct passwd                  contains     76 bytes in   6 blocks
(ref 0)
            /bin/false                     contains     11 bytes in   1
blocks (ref 0)
            /dev/null                      contains     10 bytes in   1
blocks (ref 0)
            System User                    contains     12 bytes in   1
blocks (ref 0)
            x                              contains      2 bytes in   1
blocks (ref 0)
            IUSR_JUNIPER                   contains     13 bytes in   1
blocks (ref 0)

There's 4689 copies of this, and it seems to increase roughly in proportion
to smbd's memory use.  Ie. There were 2xxx copies ealier today when it was
using half the memory.

Regards,
Jamie

> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet at samba.org] 
> Sent: Sunday, January 21, 2007 5:04 AM
> To: Christian Perrier; 407517 at bugs.debian.org
> Cc: Jamie ffolliott
> Subject: Re: [Pkg-samba-maint] Bug#407517: weekly 
> Samba/ldapsam failureserving files to a busy win2k client
> 
> On Fri, 2007-01-19 at 06:58 +0100, Christian Perrier wrote:
> > severity 407517 important
> > forwarded 407517 https://bugzilla.samba.org/show_bug.cgi?id=4282
> > thanks
> > 
> > > 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.
> > 
> > That seems to fit the definition of "important". It can't 
> be critical, 
> > IMHO.
> > 
> > I'm sorry to say that this means that the chances that this bug is
> > *not* fixed in etch are pretty high because such bugs are 
> very likely 
> > to be fixed in a new upstream version with low chances that 
> a backport 
> > is possible (but, who knows?).
> > 
> > 
> > > 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
> > 
> > 
> > Thanks for the hints that will help us to track down 
> upstream activity 
> > on the bugs.
> > 
> 
> Valgrind logs would help a lot here, with the 
> --leak-check=full option.
> In particular, valgrind's output into the logs when the 
> memory-chewing smbd is killed could be useful.  There is also 
> an smbcontrol command 'pool-usage' that, if the process is 
> still responsive, could list where the memory is being used.
> 
> Andrew Bartlett
> 
> -- 
> Andrew Bartlett                                
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Red Hat Inc.                  http://redhat.com
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-usage.28304.gz
Type: application/x-gzip
Size: 17381 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20070121/54af7fad/pool-usage.28304-0001.bin