Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
On Tue, Jun 29, 2004 at 02:03:11AM +0100, Matthew Wilcox wrote:
> On Mon, Jun 28, 2004 at 05:24:37PM -0700, Tyler 'Crackerjack' MacDonald wrote:
> > I can understand the kernel not knowing that the memory is no longer used
> > if there was still a straggler process hanging onto it. But when there are
> > no processes left to access it, why does this continue to happen? If memory
> > doesnt belong to any process at all, shouldn't it be, well, free? Regular
> > memory works this way, files and filehandles work this way, why doesn't
> > shared memory? Is it really that hard to keep a count of running processes
> > that have opened a shared memory segment?
[1]
> It wouldn't be hard for the kernel to do at all. But unfortunately,
> the crack-smokers who wrote POSIX.4 decided that IPC was different.
> The kernel is *required* to keep them around after all processes exit.
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.
> > And if this is a deficiency of the linux kernel, shouldn't APR, as a
> > Portability library, be ready to handle this quirk and clean up for you,
> > either automatically, or via a portable equivalent to ipcrm, etc?
>
> Yes, I would agree with that.
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.
Just my 0.02$
Ralf Mattes
[1] BTW, it wouldn't be _that_ easy for the kernel to handle shm cleanup. All other
resources mentioned (files, memory, sockets etc.) are tied to data structures
associated with a _process_ (which obviously doesn't work with _shared_ memory :-)
The kernel would have to keep track of the number of processes refering to the shm
segment (kind of a refcounting garbage collection). The kernel does this for inodes,
so it's technically possible, but it would need major rewriting ......
>
> --
> "Next the statesmen will invent cheap lies, putting the blame upon
> the nation that is attacked, and every man will be glad of those
> conscience-soothing falsities, and will diligently study them, and refuse
> to examine any refutations of them; and thus he will by and by convince
> himself that the war is just, and will thank God for the better sleep
> he enjoys after this process of grotesque self-deception." -- Mark Twain
>
>
> --
> To UNSUBSCRIBE, email to debian-apache-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: