topic Re: shared memory not released in Operating System - HP-UX

shared memory not released

Corinne HEINRICH — Tue, 23 Jul 2002 15:41:06 GMT

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

Re: shared memory not released

Christopher McCray_1 — Tue, 23 Jul 2002 15:43:51 GMT

Hello,

Have you done ps -fu daemon?

What does this say?

Chris

Re: shared memory not released

Uday_S_Ankolekar — Tue, 23 Jul 2002 15:47:56 GMT

Hello,

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

Goodluck
-USA..

Re: shared memory not released

Corinne HEINRICH — Tue, 23 Jul 2002 16:00:19 GMT

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

Re: shared memory not released

Jean-Luc Oudart — Tue, 23 Jul 2002 16:00:37 GMT

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

Re: shared memory not released

Don Morris_1 — Tue, 23 Jul 2002 16:21:29 GMT

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.

Re: shared memory not released

A. Clay Stephenson — Tue, 23 Jul 2002 16:48:52 GMT

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.

Re: shared memory not released

Bill Hassell — Tue, 23 Jul 2002 22:03:04 GMT

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/

Re: shared memory not released

Mladen Despic — Wed, 24 Jul 2002 13:43:05 GMT

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