Is there some way to tell what processes are attached to a shared memory segment? We have a system on which I perform "icps -ma" and there are several segments pending deletion having numerous processes attached to them and I can't tell what processes they are. Neither the creator's pid nor last pid that touched them, as listed by ipcs -mp, exist. I'm at a loss.... Is there a command I can execute that will tell me what is attached?
I think just do only a our write a code :rolleyes:
Because Kernel is process management director and itself do it automatically..:o
For example let be we have two process and we share the same memory segment.
Firstly we use shmget() syscall for create memory portion
int shmget(key_t key, size_t size, int shmflg);
The key value in here "key" gives a identifier for memory portion
"size" gives a shared memory size
"shmflag" is used to choose "0700" .Because we want to create new memory portion..
If function success then return value gives to us "shared memory segment ID"..So Then return value from shmget gives shmid value..
For add to address space we use shmat()
void *shmat(int shmid,const *shmaddr,int shmflg);
let it be
shmaddr = NULL -- > let the kernel choose a suitable address at which to attach the our shared mem segment portion..
shmflg = 0 --> because of NULL no neccessary set the flag
And then if shmat is successfull it returns shared mem segment address..
So we get the SHR address 
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <unistd.h>
#include <sys/wait.h>
#define SHMSIZE 4096 /* 4K for shared mem segment */
int shmid, *shmptr ;
key_t mykey ;
mykey=123
shmid = shmget(mykey, SHM_SIZE, 0700 | IPC_CREAT) /* create shr mem segment */
shmptr = (int *) shmat(shmid, NULL, 0); /* attach segment mem to a pointer to it */
We create 4K SHR memory space..And we have a address pointer that called name shmptr..Then anyway we use it in our process (in c code..)
I know how to use a shared memory segment in code. What I'm asking for is a command that will tell me all the processes PIDs that have called shmat for the memory. More specifically, all the processes that have called shmat and have not subsequently called shmdt. The kernel knows this, because the it holds the memory mapping for all processes. I just need to know how to make it tell me.
For more specifics, in the case I'm experiencing, some process has called shmctl asking for it to be deleted (second parameter passed as IPC_RMID) and until all processes have called shmdt the kernel must hold the segment. It flags this (as shown by ipcs) two ways: 1) it changes the key to 0xFFFFFFFF (in Linux it is 0x00000000), and 2) it shows a 'D' in the first character of the MODE column (don't see this in Linux). The first is not sufficient to say it's pending deletion because process private keys are also listed as 0xFFFFFFFF (0x00000000 in Linux). So, in Linux it seems there is no good way to see (via ipcs) that the segment is pending deletion. Either way, the shared memory segment will linger until every processes has called shmdt. Therefore, I need to know what processes need to be killed so it goes away.
P.S. It is quite annoying that the kernel switches the key.... I believe I know why it does it, and that's because a subsequent create for the key must succeed. But, it's just bloody annoying because at the very least it could hold the old value and list that with ipcs...but...whatever. Just means I'm guessing as to which key is being held on too longer than it should be.
let happen help to you output pmap command ?
pmap $pid
pmap (in Linux) will show shared memory attachments. Unfortunatly pmap does not exist for AIX and it's "equivallent" as listed by IBM (procmap) doesn't show shared memory attachments.
I'm have no access to AIX machine right now to verify, but you could try svmon, check this article.
---------- Post updated at 10:10 PM ---------- Previous update was at 09:45 PM ----------
Just to add that those segments may be orphans now (and the processes gone, it is often the case with crashed Oracle database instances, then you need to issue ipcrm carefully :)).
Well...it looks like that would work...alas, svmon is not executable by anyone other than root on our machines.... I'll see if I can get that fixed. Thanks!
Any other commands that may do it in light of the root problem?
---------- Post updated at 04:32 PM ---------- Previous update was at 04:29 PM ----------
How can that happen? The kernel should clean up after the process ends, so while it is possible that no one ever flagged the segment to be deleted, if it does get flagged, when every process ends/dies it should go away.
First off it should be noted that this behavior could be (is) platform specific and I'm not sure if this is possible on AIX, because I don't have a lot of experience with this OS/platform.
I had such an experience with Sun Solaris, but I don't remember if this was because of orphaned semaphores or shared memory segments.
I believe that for shared memory segments in that case the ipcs column nattch (number of attached processes), if present, should be 0.
It can happen with semaphores too (this is documented in MetaLink's note Unix Semaphores and Shared Memory Explained (Doc ID 15566.1)):
I suppose that this behavior might be only specific to old (and in some cases buggy) kernels/OS/SW versions.