Shared memory - not being freed / cannot use ipcrm

[Gary Hansford]

I'd rather not reboot this box to clear the shared memory segments (as this has happened before on 5.1b)...

ipcs -a shows: -

Message Queues:
T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QN
UM QBYTES LSPID LRPID STIME RTIME CTIME
q 0 0x41a90511 --rw------- root system root system 0
0 65535 524389 524858 15:17:01 15:17:01 20:12:17

Shared Memory:
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH
SEGSZ CPID LPID ATIME DTIME CTIME
m 0 0 D-rw------- ingres users ingres users 1
589824 942895 1016901 10:18:33 10:18:33 9:43:45
m 1 0 D-rw------- ingres users ingres users 1
147693568 942942 943258 9:56:49 10:17:56 9:43:45
m 4 0 D-rw------- ingres users ingres users 1
164118528 943264 944055 9:43:55 10:11:29 9:43:48
m 5 0 D-rw------- ingres users ingres users 1
482795520 943264 944055 9:43:55 10:11:29 9:43:48
m 6 0 D-rw------- ingres users ingres users 1
8192 943264 944055 9:43:55 10:11:29 9:43:53
m 7 0 D-rw------- ingres users ingres users 1
5210112 943264 944055 9:43:55 10:11:29 9:43:53
m 11 0 D-rw------- ingres users ingres users 1
3686400 944254 944275 9:43:55 9:43:55 9:43:55

Semaphores:
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OT
IME CTIME
s 0 0x696e6974 --ra-r--r-- root system root system 8 20:1
2:17 20:12:17
s 1 0x41a90511 --ra------- root system root system 1 20:1
2:16 20:12:16
s 514 0 --ra------- httpd httpd root system 1 no-e
ntry 20:14:25
s 3 0 --ra------- httpd httpd root system 1 no-e
ntry 20:14:25

It seems to think that a task is holding the memory segments 0 thru to 11. None of the PID's exist on the system. ipcrm -m xx just gives "ipcrm: shmid(xx): not found"

How can I get this shared memory back or find out what is actually holding it from being released ??

[Dave Bechtold]

Hi Gary,

It seems that the owner process that created the shared memory segment exited without at least un-attaching itself from the memory and that possible the shared memory is wired in physical memory. The NATTACH is 1 therefore the shared memory IPC sub-system believes there is a consumer of the memory, yet as you pointed out there is not. If NATTACH is 1 and you ipcrm -m {ID}, remove a segment, it will wait until the NATTACH is 0 before deleting it.

I'd want to understand why the process which setup the shared memory segment exited without first detaching itself from the shared memory. Maybe the process run by ingres is failing abnormally ?

I think your only recourse to safely recover this memory is to reboot.

Dave Bechtold

[Michael Schulte zur Sur]

Hi Dave,

it should not matter, whether the process failed abnormally or not. In any case, the os is the the one, which ends a process and releases the held resources, so why not here!

regards

Michael

[Dave Bechtold]

Hi Michael,

It's the responsibility of the creator of the Shared Memory to destroy the shared memory. Depending on the application it may destroy the shared memory segment upon a normal exit, SIGTERM causes the process to exit and in doing so cleans up and destroys the shared memory. But, the shared memory will not be destroyed until all ATTACHes to that memory detach themselves - then the shared memory segment will be removed from the system.

Now that I look at this a bit closer - your shared memory segments have an KEY of "0" thus the ipcrm failing with "not found", but the NATTACH is non-zero meaning another consumer of the shared memory is attached, or at least we believe it's still attached - it never detached it's reference to the shared memory. Maybe it exited abnormally ?

So, when you say "None of the PID's exist on the system." are you saying that none of the CPID's, creator of the shared memory, or LPID's, last process to attach/detach the shared memory segment, exist on the system?

If that's the case I'd expect that the CPID process exited cleanly and marked the segment to be destroyed/removed but it remained because of the other LPID process had an attachment and that process exited abnormally with out first detaching from that segment. In that scenario I'm not sure the OS would know to actually remove the segment since it was never asked to detach it from the LPID.

Dave Bechtold

[Gary Hansford]

David / Michael,

In this particular case, the owner should be ingres. The ingres DBMS servers had been dropped via a "kill -9" (as it had totally stopped responding). There were no ingres userid/PID's on the system at all. In fact before the reboot there was nothing apart from OS pid's running.

Nope, it looks to me as though a kill -9 against a process holding shared memory can result in you being unable to free that memory without a reboot.

Reboot cures by the way (but hey we knew it would - because thats a standard MS Windoze answer !).

Cheers

Gary

[Ralf Puchner]

shared memory must be freed by the program. If the application is not properly developed (e.g. kill signal does not lead to cleanup) memory will be still allocated.

In your case the "Deletion" was forced (mode contains the flag "D"), but memory will not be freed until the last process detaches the segment (see "man ipcs" for a description).

Have you checked if a defunc process is still running?