[tpop3d-discuss] Memory leak?

[Chris Lightfoot]

On Wed, May 08, 2002 at 01:07:34PM -0700, Marc Lewis wrote:
> On Wed, May 08, 2002 at 06:38:07PM +0100, Chris Lightfoot wrote:
> > On Wed, May 08, 2002 at 10:12:52AM -0700, Marc Lewis wrote:
> > > On Wed, May 08, 2002 at 11:40:56AM +0100, Chris Lightfoot wrote:
    [...]
> I've been running some tests using the auth-ldap module, and it appears
> that the leak is still there.
> 
> When first starting up the daemon:
> 
> root     10829  0.0  0.1  4788 1900 pts/1    S    12:18   0:00 /usr/src/tpop3d-1.4.1/tpop3d -f /etc/tpop3d-test.conf -d -v
> 
> After about a hundred or so mail checks (on a different port):
> 
> root     10829  0.0  0.1  4836 1948 pts/1    S    12:18   0:00 /usr/src/tpop3d-1.4.1/tpop3d -f /etc/tpop3d-test.conf -d -v
> 
> Looks like it has grown by about 48K.  So, it appears to be a small leak,
> but there none the less.

Errm. I'd want to run the test for a bit longer than that
to be sure-- a change of 48k could just be `noise'. How
much does it grow after a few thousand checks?

> I know this is hackish sounding, but what is the motivation for doing all
> of the auth and such before forking?  When I've written simple daemons and

When I originally wrote tpop3d, I wanted a POP server
which would interact with a relational database in a
sensible way; this means not setting up a database
connection for every time a user connects to the service.
Hence this choice of design. I agree with your comments
about forking servers in general, but you do take a
significant performance hit from this.

> I will probably end up hacking in a new option to tpop3d to make it not
> detach from the controlling TTY and not send out debugging information to
> stderr.  This is how we ran our old pop3 server (cucipop) before switching
> to Maildir format.  Dropping it into inittab made sure that even if the
> parent died, it would be restarted.

tpop3d -d 2> /dev/null ?

> > > > Also, can you tell me more about the crashes you've
> > > > experienced -- in particular, is there any useful
> > > > information in the logs?
> > > 
> > > Nothing.  Things just stop.
> > 
> > Hmm. That could just be an out-of-memory issue, I suppose.
> > Or possibly something timing out connecting to the LDAP
> > server?
> 
> We hadn't seen any timeouts like this when we were using Courier POP, but
> it often corrupts attachments over 500K (the first reason we switched to
> tpop3d).  We also have a lot of IMAP usage for our Webmail services and
> haven't seen any timeouts at all (big LDAP in-memory caches are setup).

I take it that the Courier IMAP server doesn't suffer from
a memory leak of this type? Its PAM implementation looks
much like that in tpop3d, but it's possible that it forks
after accept, in which case this wouldn't be apparent.

    [...]
> > Yep-- I've seen this before. It's a bug in one of the PAM
> > authentication modules, which is evidently calling
> > openlog(3) and changing which log file the thing is
> > writing to. Sigh. Try the following patch:
> [snip]
> 
> Thanks, I'll give the patch a try and see if it makes a difference.  If it
> is a PAM bug, this may be a moot patch anyway if we end up going with
> straight LDAP authentication.

Yeah. It should probably be in there anyway because of PAM
bogusness.

> > (You probably don't all want to hear me rant about PAM.
> > Let me just say that, for a security-critical component of
> > the operating system, it is astonishingly shoddily
> > implemented. Coupled with a loudy design and poor
> > documentation, I'm surprised that it works at all.)
> 
> Actually, I feel similar about PAM, this was our first heavy usage of it
> beyond what RedHat provides in their stock distributions.  But, because of
> the way we are rolling out new servers, PAM + LDAP is a good way for us to
> keep a single configuration and secure authentication mechanism in place
> for a whole network of servers that all need to have the same user
> information for POP, IMAP, Apache userdir and auth, SASL, FTP, SSH, etc,
> etc, etc..

Yep. I did some work on a Postgres-based solution for this
(to me, LDAP looks more like a buzzword than a solution,
but I imagine this puts me in a minority...).
Unfortunately it required implementing a PAM password
changing thing, which taught me more about PAM than I wish
to know.

In particular, password-changing modules are expected to
do their own authentication, so that (e.g.) the ability of
UID 0 to change any password is implemented as a feature
of the password changing module(!). Apart from being
entirely the Wrong Way to do this, it's also not
documented. Ugh.

Perhaps there is a `next-generation' PAM replacement, but
if there is, I'd probably rather not know any more about
it.

-- 
``DO NOT perform mouth-to-mouth resuscitation....''
  (EPA emergency care advice for victims of the nerve gas sarin)