(forw) [dfries@mail.win.org: Bug#161253: apache2: shared memory cleanup]

[Thom May <th...@planetarytramp.net>]

I'm forwarding this debian bug onto the dev list for discussion and
comments.
please can the cc line (161253@bugs.debian.org) be maintained so the bug
gets a record of this?
Cheers,
-Thom
-- 
Thom May -> thom@debian.org

< robster> SHIT
< robster> woody doesnt support devfs
< willy> devfs is FUcking Shit
< liiwi> willy: quick now! tell it to stop before it gets itself dirty!

Re: (forw) [dfries@mail.win.org: Bug#161253: apache2: shared memory cleanup]

[Bojan Smojver <bo...@rexursive.com>]

On Wed, 2002-09-18 at 19:24, Thom May wrote:

> Shared memory (as used by at least the ssl module) needs to rethink
> how they go about cleaning it up.  Currently kill -9 the apache
> processes or it would appear that even /etc/init.d/apache2 reload will
> cause apache to fail to start because the shared memory segment can't
> be created since it already exists.

I can confirm that. Given me a headache many times...

Bojan

Re: (forw) [dfries@mail.win.org: Bug#161253: apache2: shared memory cleanup]

[Justin Erenkrantz <je...@apache.org>]

On Fri, Sep 20, 2002 at 10:16:35AM -0700, Aaron Bannert wrote:
> An alternative, since Debian/Linux has a robust VM system, would be
> to make sure Apache uses an mmap()-based shared memory syscall. This
> would take some tweaking of the autoconf scripts.

I think the autoconf tests already detect mmap() on Linux, but we
can't use that as SSLSessionCache uses named shared memory
exclusively.

I think we should add anonymous shared memory support to mod_ssl's
session caches, but that'd be too easy a solution.  -- justin

Re: (forw) [dfries@mail.win.org: Bug#161253: apache2: shared memory cleanup]

[Aaron Bannert <aa...@clove.org>]

On Wed, Sep 18, 2002 at 10:24:43AM +0100, Thom May wrote:
> Shared memory (as used by at least the ssl module) needs to rethink
> how they go about cleaning it up.  Currently kill -9 the apache
> processes or it would appear that even /etc/init.d/apache2 reload will
> cause apache to fail to start because the shared memory segment can't
> be created since it already exists.

Any time you use SIGKILL you're going to have to manually clean up
semaphores, segments, and other shared resources. The solution to
that is to not use kill -9.

> There are a couple solutions to this.  If the shared memory segment
> already exists just attach to it, but this has security issues.

It's not so much about security as it is about not knowing if there
is a current generation of httpd processes still using it or if it's
safe to jump right in and start reusing the same segment. I can't
think of any robust ways to detect this.

> If the shared memory segment already exists pick another magic number
> and try again, this could eventually leave many unused shared memory
> regious laying around.

At some point you will run out of system resources. The right thing
to do is to not use kill -9 and if you must, to make sure you clean
up your shared resources.

An alternative, since Debian/Linux has a robust VM system, would be
to make sure Apache uses an mmap()-based shared memory syscall. This
would take some tweaking of the autoconf scripts.

> This is how I've done it in the past.  Allocate the shared memory
> segment, attach to it, delete it.  It will stick around until the last
> process detaches.  We just need to use the shmid to attach to our
> segment instead of using the key.

I tried this when I was writing the new apr_shm.h stuff, but the problem
is once you mark a segment for deletion, no new processes can attach
to it (including children, if I remember correctly).

-aaron

Re: (forw) [dfries@mail.win.org: Bug#161253: apache2: shared memory cleanup]

[Greg Stein <gs...@lyra.org>]

On Wed, Sep 18, 2002 at 10:24:43AM +0100, Thom May wrote:
>...
> please can the cc line (161253@bugs.debian.org) be maintained so the bug
> gets a record of this?

Well, dunno about that. Since this list obeys Ken's nefarious insistence on
Reply-To munging, who knows what'll happen when people reply?

<ducks>

:-)

-- 
Greg Stein, http://www.lyra.org/