Re: [tpop3d-discuss] Memory leak?

[Marc Lewis]

On Thu, May 09, 2002 at 11:20:45AM +0100, Chris Lightfoot wrote:
> On Wed, May 08, 2002 at 03:57:50PM -0700, Marc Lewis wrote:
> > On Wed, May 08, 2002 at 11:20:07PM +0100, Chris Lightfoot wrote:
>     [...]
> > > I may add an option to have it restart itself every so
> > > often.
> > 
> > After looking through the code a bit more, I can see the hesitation in
> > making this an option.  Would require major reworking.
> 
> Well, allowing it to restart itself automatically isn't
> too bad, as long as you're happy to allow it to drop any
> pre-authenticated connections, as happens when you send
> the daemon a SIGHUP. It would be nicer not to have to do
> this, which means either
> 
>     1.  waiting until there are no pending connections,
>         then restarting; or
> 
>     2.  closing the listening socket, then forking a new
>         process to take it over, and exiting once all of
>         the current connections are closed.
> 
> Observe that the second of these doesn't help with the
> case where an inbound connection is in the listen queue
> but hasn't been accepted yet.
> 
> Of course, you could just put 
> 
>     kill -HUP $(cat /var/run/tpop3d.pid)
> 
> in crontab to run every twelve hours or something. Until
> I've got to the bottom of the memory leak problem, this is
> probably the simplest workaround.

This would be hard to do in our environment.  Users are rather unforgiving,
and I'm nearing the end of the timeline to do this.  Systems like this need
to be put into place and then forgotten about.  It appears that our
environment may not be a good match for tpop3d, which is quite unfortunate,
as I really like the way it does things.

>     [...]
> > > Which version of the OpenLDAP libraries are you using?
> > 
> > v2.0.21-1 from RedHat 7.2 installation, then updates.
> 
> Cheers. I'll see if I can reproduce anything with my test
> OpenLDAP installation.

I'm very interested to hear your results.  

Thanks.

 - Marc

-- 
Marc Lewis
Network Administrator
Blarg! Online Services, Inc.
http://www.blarg.net/~marc