[ARKSPAM] Re: Re: [Samba] Samba 3.0.14 (Debian Sarge) Memory Leakage

[it]

Hi all,

I have the same problem.
We are using version 3.0.14a under Debian Sarge
and after installing a local printer/fax HP LaserJet 3050,
the memory server is allocated to the user session until reaches 100%.
I don't know how to avoid it.

Mike

----- Original Message -----
From: Volker Lendecke <Volker.Lendecke at SerNet.DE>
To: Dirk Becker <dirk.becker at symeo.com>
Cc: samba at lists.samba.org, Christian Merker <christian.merker at symeo.com>
Sent: vendredi 17 novembre 2006 19 h 57 GMT+0100 Europe/Berlin
Subject: [ARKSPAM]  Re: [Samba] Samba 3.0.14 (Debian Sarge) Memory Leakage

On Tue, Nov 14, 2006 at 10:34:31AM +0100, Dirk Becker wrote:
> Our Samba file server seems to have a memory leakage. We are using samba
> as file server out of the box (debian sarge) on kernel 2.6.16.31.
> After a while users who have some shares and files open are acquiring
> more and more memory until the smbd dies.

A wild guess is that this might be printer related instead
of file related.

> Here is a small shortcut from top:
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 13843 gxxxxx    16   0 51792  44m 2552 S  0.3 17.8   0:22.97 smbd
> 13840 bxxxxx    17   0 31400  25m 2764 S  0.7 10.0   2:42.78 smbd
> smbd is allocation and more memory. We are using user security and
> smbpasswd as password backend.

Ok, 44M is a lot but not entirely out of scope, depending on
what your clients do. But it's very likely a memleak, true.

> The output from 'smbcontrol 13843 pool-usage' shows:
> global talloc allocations in pid: 13843
> name                                       chunks    bytes
> ---------------------------------------- -------- --------
> msg_pool_usage                                  1      159
> lp_talloc                                       2        2
> connection_struct                               1     1844
> pipe spoolss 0x922dfb0                          0        0
> pipe spoolss 0x83f4380                          0        0
> connection_struct                               1     1844
> connection_struct                               1     1844
> passdb internal SAM_ACCOUNT allocation         19      493
> passdb internal SAM_ACCOUNT allocation         17      503
> pdb_context internal allocation context         5     1513
> passdb internal SAM_ACCOUNT allocation          8      397
> ---------------------------------------- -------- --------
> TOTAL                                          55     8599

Ok, this looks innocent. So we have a problem out of the
talloc memory space.

How deep do you want to go? :-)

I would do several steps: First, try with 3.0.23d. Second,
recompile with -g and run smbd under valgrind
--tool=memcheck. Be aware that valgrind makes smbd at least
10 times slower, so this is something for a non-productive
server. Then get some smbd to chew that memory, and shut it
down by disconnecting from the client or sending it the
shutdown command. valgrind will then show you the blocks
allocated and not freed, so we will at least see the
allocation places that leak.

Volker