Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash

* Tyler 'Crackerjack' MacDonald <tyler@xxxxxx>
| 
| If I set up an apr_shmem segment on my Debian GNU/Linux system, and the
| master process that set up the segment crashes without closing it, the
| segment sticks around until I reboot.

That's expected.  Since shared memory doesn't belong to a specific
process, the kernel will not know when to clean up the memory.

| I'm using a file named "libbtt.shm" to back the segment on the filesystem,
| but even if i delete that file, and no other processes are running that
| access the segment, when I re-start the server I get the following error:

The information about the shared memory still resides in the kernel, so
deleting the file won't do much.  For cleaning up you want to look at
ipcs(8) and ipcrm(8).

| "apr_shm_create(&rv, 880, ".../libbtt.shm", pool) failed: File exists"

My guess is that shm_open thinks the file already exists because the
shared memory was not cleaned up properly (although ".../libtt.shm" is a
bit odd relative path).

-- 
Øyvind Grønnesby


-- 
To UNSUBSCRIBE, email to debian-apache-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx