shared memory not released

[Corinne HEINRICH]

hello,

I'm looking for q way to trace which deamon has used some shared librairies and never released them. In the attached document there is an outpu of ipcs -a command. You can see that shared memories are overflown because of on deamon which may crash without releasing its associated shared memory.
If someone has an Idea about how to investigate this problem, I would appreciate.

thanks

[Christopher McCray_1]

Hello,

Have you done ps -fu daemon?

What does this say?

Chris

[Uday_S_Ankolekar]

Hello,

you can release them by ipcrm command.
ipcrm -m id# You need to remove only thos which has 0 NATTACH..

Goodluck
-USA..

[Corinne HEINRICH]

thanks all,

for ps -fu deamon, there is no result. the list is empty.

For ipcrm, I've tested it before qnd I cannot kill deamon shared memory.

henry

[Jean-Luc Oudart]

Hi Corinne,

Got a similar problem where the program was killed and the shared memory not released.
I wrote a script to detect if any of the process attached to the shared memory is still active. This generates a "ipcrm command" into a file that is then executed.
cf. attached script

Jean-Luc

[Don Morris_1]

You should be able to ipcrm daemon memory as superuser.

As far as tracing which daemon - assuming the pids are dead at this time the only thing I can think of would be to have a script running once a second to parse the output of ipcs -ma, get only the daemon lines, cut out the LPID or CPID and do a ps -ef |grep (or equivalent). The pid is the only data about the processes that gets embedded in the shared memory descriptor so you'll have to catch one before it dies.

[A. Clay Stephenson]

One thing to keep in mind that while NATTACH=0 is a necessary condition; it may not be a sufficient condition. You see, some software is written to expect the presense of a shared memory segment that may well have been created by another process. While at the moment, no processes are attached to that segment, the application might well crash if it can't find the expected shm segment when it is started. It depends on how the software was written.

[Bill Hassell]

As mentioned, once the process is gone (and did not properly release shared memory) there is no way to track it. Shared memory can be created by one process and then used by other processes without the original process staying around.

As you've seen, the daemon is crashing and leaving the segments orphaned. There are two choices:

- fix the daemon so it doesn't crash
- reboot every day

Sometimes you have weigh the pain associated with getting a broken process fixed versus the pain of rebooting. For more details (beyond ipcs) about shared memory, get a copy of shminfo from:

ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/

[Mladen Despic]

Corinne,

If you have Glance, it may be helpful to use it.
The attached file is "adviser syntax" which I have used in the past for troubleshooting similar problems.

Instructions:

1. Save the attachment to your current directory - let's call it shmem.syntax

2. Run

glance -adviser_only -syntax shmem.syntax -j 60 -f /tmp/glance.out

3. View the log file:

/tmp/glance.out

Regards ... Mladen