How to associate a semaphore with a PID?

[zhaogui]

Can anybody tell me how can I associate a semaphore with a process ID?
#ipcs -sa
ixos3:/ #ipcs -sa
IPC status from /dev/kmem as of Tue Jun 25 16:29:17 2002
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME
Semaphores:
s 0 0x411c38e8 --ra-ra-ra- root root root root 1 16:56:36 16:56:29
s 1 0x4e0c0002 --ra-ra-ra- root root root root 2 16:56:32 16:56:29
s 2 0x41204618 --ra-ra-ra- root root root root 2 16:57:48 16:56:30
s 3 0x01090522 --ra-r--r-- root root root root 1 no-entry 16:57:50
s 4 0x61204080 --ra-ra-ra- root root root root 1 16:59:02 16:58:13
s 5 0x73204080 --ra-ra-ra- root root root root 1 16:27:07 16:58:13
s 6 0x70204080 --ra-ra-ra- root root root root 1 16:59:02 16:58:13
s 7 0x69204080 --ra-ra-ra- root root root root 1 16:59:02 16:58:13
s 8 0x75204080 --ra-ra-ra- root root root root 1 16:58:14 16:58:13
s 9 0x63204080 --ra-ra-ra- root root root root 1 16:58:13 16:58:13
s 10 0x64204080 --ra-ra-ra- root root root root 1 16:59:04 16:58:13
s 11 0x66204080 --ra-ra-ra- root root root root 1 no-entry 16:58:13
s 12 0x6c204080 --ra-ra-ra- root root root root 1 16:59:02 16:58:13
s 13 0x6d204080 --ra-ra-ra- root root root root 1 16:27:07 16:58:13
s 14 0x6f204080 --ra-ra-ra- root root root root 1 no-entry 16:58:13
s 15 0x410c0342 --ra-ra-ra- root root root root 1 16:58:15 16:58:15
s 16 0x00446f6e --ra-r--r-- root root root root 1 no-entry 16:58:18
s 17 0x00446f6d --ra-r--r-- root root root root 1 no-entry 16:58:18
s 18 0x52204080 --ra-ra-ra- root root root root 1 11:26:22 16:59:04
s 18219 0xf62f87d8 --ra-ra---- orasmo dba orasmo dba 84 16:29:10 15:28:27

Before I run ipcrm to remove certain crippled semaphore, how do I know it belongs to which process?

Thanks,

[Ian Dennison_1]

Run 'ipcs -ma'. Look for Column CPID (Create Pid). Column LPID shows the last PID to access the area.

'ipcs' man page gives a very good description of these variables.

Share and Enjoy! Ian

[Marcin Wicinski]

Hi,
ipcs -ma shows information on shared memory segments. You can only use ipcs -spc - it shows semaphore creator and owner id.

Later,

[zhaogui]

No process id?

[Paula J Frazer-Campbell]

Hi

See man ipcs.

ipsc -p

T ID KEY MODE OWNER GROUP CPID LPID
Shared Memory:
m 0 0x2f100002 --rw------- root root 382 4066
m 1 0x411c061a --rw-rw-rw- root root 539 539
m 2 0x4e0c0002 --rw-rw-rw- root root 539 539
m 3 0x41200534 --rw-rw-rw- root root 539 551
m 8196 0x0c6629c9 --rw-r----- root root 1546 24873
m 5 0x06347849 --rw-rw-rw- root root 1546 1563
m 6 0xffffffff --rw-r--rw- root root 1526 1526
m 5127 0xacec9411 --rw-rw-rw- root root 1612 17250


Paula

[zhaogui]

I think Process ID is only available to Message queue and Shared memory but not Semaphore, am I right?

#ipcs -p
IPC status from /dev/kmem as of Tue Jun 25 17:21:40 2002
T ID KEY MODE OWNER GROUP LSPID LRPID
Message Queues:
q 0 0x3c1c3905 -Rrw--w--w- root root 0 0
q 1 0x3e1c3905 --rw-r--r-- root root 0 0
T ID KEY MODE OWNER GROUP CPID LPID
Shared Memory:
m 0 0x411c38e8 --rw-rw-rw- root root 810 810
m 1 0x4e0c0002 --rw-rw-rw- root root 810 812
m 2 0x41204618 --rw-rw-rw- root root 810 812
m 22787 0x2e955e28 --rw-rw---- orasmo dba 14236 5041
m 3076 0x00000000 D-rw------- orasmo dba 12269 12269
m 6 0x06347849 --rw-rw-rw- root sys 18724 9709
Semaphores:
s 0 0x411c38e8 --ra-ra-ra- root root
s 1 0x4e0c0002 --ra-ra-ra- root root
s 2 0x41204618 --ra-ra-ra- root root
s 3 0x01090522 --ra-r--r-- root root
s 4 0x61204080 --ra-ra-ra- root root
s 5 0x73204080 --ra-ra-ra- root root
s 6 0x70204080 --ra-ra-ra- root root
s 7 0x69204080 --ra-ra-ra- root root
s 8 0x75204080 --ra-ra-ra- root root
s 9 0x63204080 --ra-ra-ra- root root
s 10 0x64204080 --ra-ra-ra- root root
s 11 0x66204080 --ra-ra-ra- root root
s 12 0x6c204080 --ra-ra-ra- root root
s 13 0x6d204080 --ra-ra-ra- root root
s 14 0x6f204080 --ra-ra-ra- root root
s 18 0x52204080 --ra-ra-ra- root root
s 18219 0xf62f87d8 --ra-ra---- orasmo dba

[Steve Lewis]

Yes -ma and -qa show the pids, -sa and -sp do not show the pids. You will have to look at the create date/time and compare with that of the process, provided that the process creates the semaphores when it starts up; this is not a foolproof method if lots of processes start up at the same time, all creating semaphores.

Secondly you can look at the semaphore key. If the process uses the same key for semaphores and shared memory or message queues (which is more likely) then you can use one of the other ipcs commands (like ipcs -ma) cross-reference the KEY and get the pid from that.

It helps to have separate usernames for different shared facilities, or even better, to use commands in your product to show its own semaphore IDs.

[Stefan Farrelly]

here is a script which shows you the correct pid using each semaphore. Its slow as it needs to search the kernel tables and structures to match them up, but is the only accurate way I know of finding out the pid;

#semaphores.sh
if [ `uname -r|grep 11 >/dev/null;echo $?` -eq 0 ]
then
/usr/contrib/bin/q4pxdb /stand/vmunix 2>&1|grep "already" >/dev/null 2>&1
if [ $? -ne 0 ]
then
echo "\n/usr/contrib/bin/q4pxdb says /stand/vmunix is not ready for degbugging!"
echo "you need to run q4pxdb /stand/vmunix which will create a new vmunix "
echo "with debug mode on. Backup your current /stand/vmunix file first!!"
echo "Once you have done this you can rerun this script, dont forget to"
echo "replace your /stand/vmunix file after running this script.\n"
exit 1
fi
else
/usr/contrib/bin/q4pxdb -s status /stand/vmunix|grep "ready for debug" >/dev/null 2>&1
if [ $? -ne 0 ]
then
echo "\n/usr/contrib/bin/q4pxdb says /stand/vmunix is not ready for degbugging!"
echo "you need to run q4pxdb /stand/vmunix which will create a new vmunix "
echo "with debug mode on. Backup your current /stand/vmunix file first!!"
echo "Once you have done this you can rerun this script, dont forget to"
echo "replace your /stand/vmunix file after running this script.\n"
exit 1
fi
fi
let V=0
let LOOP=`ipcs -bs|wc -l`
let LOOP=$LOOP-3
ipcs -bs|head -1
echo "T ID KEY MODE OWNER GROUP NSEMS PID\nSemaphores:"
ipcs -bs|tail -$LOOP|while read A B C D E F G
do
echo "$A $B $C $D $E $F $G \c"
ied q4 /stand/vmunix /dev/mem </tmp/tmp.$$ 2>/dev/null
load struct seminfo from &seminfo
load struct semid_ds from &sema count $LOOP
keep indexof == $V
load struct __sem from sem_base
print sempid
EOF
cat /tmp/tmp.$$|grep -v sem
let V=$V+1
done

[Stefan Farrelly]

Im not sure the formatting of my script came out to well when I pasted it so here it is as an attachment.

Cheers,

Stefan

[Stefan Farrelly · Accepted solution]

Im not sure the formatting of my script came out to well when I pasted it so here it is as an attachment.

Cheers,

Stefan

[Stefan Farrelly]

Dont paste the script to a file - you will lose all the tab characters which are essential to the output formatting. Download the semaphores.sh script to a file then run it.

When you run it you will get output like;

IPC status from /dev/kmem as of Tue Jun 25 10:55:36 2002
T ID KEY MODE OWNER GROUP NSEMS PID
Semaphores:
s 0 0x411c061a --ra-ra-ra- root root 1 480
s 1 0x4e0c0002 --ra-ra-ra- root root 2 492
s 2 0x4120036e --ra-ra-ra- root root 2 492
s 3 0x00446f6e --ra-r--r-- root root 1 593
s 4 0x00446f6d --ra-r--r-- root root 1 599
s 5 0x01090522 --ra-r--r-- root root 1 636
s 6 0x612016c4 --ra-ra-ra- root root 1 1126
s 7 0x732016c4 --ra-ra-ra- root root 1 12892
s 8 0x702016c4 --ra-ra-ra- root root 1 16663

[zhaogui]

A magic script! Although I don't understand it, I must say it is brilliant! Here is the output on me server,
#./sem1.sh
IPC status from /dev/kmem as of Wed Jun 26 08:44:59 2002
T ID KEY MODE OWNER GROUP NSEMS PID
Semaphores:
s 0 0x411c38e8 --ra-ra-ra- root root 1 810
s 1 0x4e0c0002 --ra-ra-ra- root root 2 822
s 2 0x41204618 --ra-ra-ra- root root 2 822
s 3 0x01090522 --ra-r--r-- root root 1 1242
s 4 0x61204080 --ra-ra-ra- root root 1 1866
s 5 0x73204080 --ra-ra-ra- root root 1 9125
s 6 0x70204080 --ra-ra-ra- root root 1 1866
s 7 0x69204080 --ra-ra-ra- root root 1 1866
s 8 0x75204080 --ra-ra-ra- root root 1 1866
s 9 0x63204080 --ra-ra-ra- root root 1 1866
s 10 0x64204080 --ra-ra-ra- root root 1 2254
s 11 0x66204080 --ra-ra-ra- root root 1 1866
s 12 0x6c204080 --ra-ra-ra- root root 1 1866
s 13 0x6d204080 --ra-ra-ra- root root 1 9125
s 14 0x6f204080 --ra-ra-ra- root root 1 1866
s 15 0x410c0342 --ra-ra-ra- root root 1 1976
s 16 0x00446f6e --ra-r--r-- root root 1 2081
s 17 0x00446f6d --ra-r--r-- root root 1 2087
s 18 0x52204080 --ra-ra-ra- root root 1 2256
s 18219 0xf62f87d8 --ra-ra---- orasmo dba 84 14236

But when I run ps -ef|grep 14236, it says the process does not exist, why? Is it because this is an old process and it has become a history? Some processes do exist but how do I verify them? How do I know whether or not a process did create a particular semaphore? Sorry for my ignorance of semaphore.

[Stefan Farrelly]

Yes, some of the pids listed may well have died by the time you use ps to view them. But the kernel doesnt lie - these were the pids that created these semaphores (the output from this script comes direct from the running kernel).

Sometimes semaphores are not cleaned up properly if processes didnt die properly (in which case you can use the ipcrm command to remove them) but the above script is accurate.

Dont forget to assign points.

Cheers,

Stefan
HPO

[Frank Slootweg]

[This response talks mainly about semaphores, but is equally applicable to other IPC facilities, i.e. messages and shared-memory segments.]

As other have, implicitly or explicitly, indicated, IPC resources like semaphores are not owned by *processes*, but by *users*.

So 'the system' can not clean up 'left-over' semaphores and neither can the user, at least not without *additional* information about the allocation, use and deallocation.

Why? Because it is perfectly OK for a process (A) to allocate a semaphore and then terminate. So there is *no* (relevant) process, but still the semaphore can not be deallocated, because at anytime a process (A, B, whatever) could come along that wants to use the semaphore.

So basically, the documentation of the application should document how *this* application allocates, uses and deallocates IPC resources like semaphores and how 'left-over' IPC resources should be determined/deallocated.

What is normally the problem is that someone/something has abnormally terminated (i.e. kill, etc.) one or more processes which are supposed to deallocate (semctl(..., IPC_RMID)) semaphores ), so they remain allocated but not used.

If you do not have the above mentioned application documentation, you can do the following to *try* to solve *future* occurences of the problem:

Use "ipcs -a" to make 'reference listings' (in files) of different stages of system use, i.e. after boot, after starting applicationA, after starting applicationB, after starting a second instance of applicationA, etc., etc..

This will give an indication of which software is using which IPC facilities. Then, if there is a problem with running out of IPC resources, you can check if the ipcs list still matches what you expect.

Now when you have 'too many' semaphores, you *probably* can figure out which ones are left-over by comparing the current ipcs output to your reference list. If unsure, don't ipcrm the semaphore! If you are sure, pray, do the ipcrm and hope for the best!

Be aware that this method is a hack, not guaranteed and possibly dangerous. I do not support it and neither does HP.

Moral: Do not use "kill -" et al, or be prepared for the consequences! :-) Note that depending on the process, "" may be as innocently-looking as "HUP", etc.! If the documentation of a particular process does not specifically say so, then do *not* assume that intr, quit or "kill -" is safe!

*If* you 'have to' kill a process, then *document* what you did (i.e. process numbers and program names/paths/parameters (parent, children, etc.), when you did it and why.