Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
* Tyler 'Crackerjack' MacDonald [EMAIL PROTECTED] | | 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
Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
Oyvind, That's expected. Since shared memory doesn't belong to a specific process, the kernel will not know when to clean up the memory. When I was using libmm, I never had this problem. I could crash my software a dozen times in an hour and still be able to get a fresh segment. I guess that's why I didn't expect it in APR; my understanding was that APR's shared memory system was grown out of libmm. 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? 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? Also, there's a second symptom that I've started to notice. Because of this bug, I have to change my starting path each time. After 4 or 5 crashes, I don't only have to change directories, but _partitions_ as well, to get a new good segment. This really concerns me, because it seems to indicate that it's possible for two processes backing their shared memory off of different files in different directories on the same filesystem to conflict. What's the point in specifying a path if that path doesn't contribute to the uniqueness of the shared memory segment? | 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). It was actually /sanity/tr4/libbtt.shm, I just stripped the rest off because my path naming convention is silly. :) - Tyler
Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
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? 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. 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. -- 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
Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
Package: libapr0 Version: 2.0.49 Severity: normal 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. 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: apr_shm_create(rv, 880, .../libbtt.shm, pool) failed: File exists Thanks, Tyler -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-2-k7 Locale: LANG=C, LC_CTYPE=C
