Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
> No comments on the drug-abuse habbits of POSIX.4 authors :-) But there
> are actually valid patterns of use for this behavior. If you think of
> shared memory as a special case of shared file (wich is pretty much what
> it is) than it should be clear that erasing such a resource would be a
> rather, erm, dastic thing to do for the kernel.
OK.. So backtracking a bit, APR allows me to specify a filename to back the
shared memory segment.
But after a crash, if i remove this file, it claims "file exists" even
though there's no file there, presumedly because a shared memory segment
tied to that particular filename still exists.
To compound the problem, if I create a file with the same name in a
different directory on the same filesystem, sometimes (but not all the time)
I STILL get a "file exists" error. In fact, my experience has been that
after an undetermined number of crashes on a particular partition (in fact
it seems to fluxuate, sometimes 4 or 5, sometimes 10 or 20), I can't use
that partition for ANY shared memory segment anymore and have to move to a
completely different drive.
Now, from what all of you have told me, the first problem is an unfortunate
problem with POSIX.4's implementation of shared memory.
The second problem, on the other hand... If APR documents that you can
speicfy a filename to get a unique segment, and you actually can't all of
the time, that seems like a bug to me.
And I'm still confused as to why libmm doesn't experience this problem. I
suspect it has something to do with the fact that libmm requires that
processes sharing the memory have a common parent process and there's only
one "create". I'm actually considering using libmm instead, except for the
fact that the library I'm developing's primary function is to be used in an
apache2 module. I'd make much more sense to do this all exclusively with
APR. (Is there a way to make APR act more like libmm?)
I mean, I *could* just try apr_shm_create() and if that doesnt work, have
the master process apr_shm_attach() instead and clear the memory... but
that's just messy.
Maybe I'll just say "screw it all" and use an mmaped file instead for the
whopping 880 bytes of stateful information I want to track.
> Hmm, i don't think so. I can well imagine that a module _wants_ the shared
> memory stay arround during server restarts (think of stats keeping, session
> information etc.). If the semantic of your application doesn't want this,
> clean up during server startup. AFAIK Apache core soes this with the scoreboard
> file during startup.
Couldn't the master process (which doesn't change pid on "apachectl
restart") deliberately leave the handle open across the restart? Or am I
missing something else here?
Thank all of you for your help on this... this problem's been driving me
crazy since everything else I've done with APR's worked exactly as I've
expected.
Cheers,
Tyler
Reply to: