semaphor

[SIMON ; TAMÁS]

Hi ,All masters !
I work on HP-UX 11.0. I observed the fact that the number of semaphores of active interpro-
cess communication increases continually. The
third field of the gived rows by ipcs contains
a phzsical value.
I don't know identifier this adress with its
running process, therefore I can't use the ipcrm command. When the number of rows by ipcs increase over a certain value some processes terminate without errorsignal.
When and wich conditions may I remove the unused rows endevoured the enhanced security.
I'd like to take advantage of ipcrm and manage this bottleneck.

[Roger Baptiste]

Hi,

If you are running out of semaphores on the system, then you would be better of increasing
the the number of semaphores (semmns) in
the kernel, rather than trying to release
semaphores using the ipcrm command.

ipcrm command is used to release semaphores
which are not being used by any process,
i.e the NATTCH should be 0 in the ipcs -as
command output. Otherwise the results of
using the command will be unpredictable.

-raj

[Rita C Workman]

RajMan makes a very good point here. Unless you can positively identify something you don't want to kill it.
And let me add...unless you know what is running, and more importantly what and how it runs, don't kill. Example:
a little known, and not often seen daemon, used by an application running here, (dldd) can be deadly if you try to kill using ipcrm. This daemon manages address spaces across processes requesting to share vtables of objects defined within shared libraries. See the headache here...
My point being...be sure of everything going on in the background, before you start killing something.
As RajMan said it is much easier to increase semmaphores...if you have the resources.

Just a thought,
Rit

[harry d brown jr]

I totally agree with Raj, the damage that one can inflict on oneself with ipcrm is greater than increasing the number of semaphores. If you have an application issue, get it fixed.

If you remove the wrong semaphore, you could unleash hell, possibly corrupt your database, crash your system, toast your users, etc...

live free or die
harry

[Uday_S_Ankolekar]

Hi,

Run ipcs -moba

look for the coloumn NATTACH with zero attachments. This semaphor can be be saftley killed by ipcrm -m followed by the number

Goodluck
-USA..

[Frank Slootweg]

Not wanting to be pedantic, but 1) NATTCH is for shared memory segments, not semaphores and 2) even NATTCH being zero does not neccessarily mean that it is totally safe to remove a shared memory segment, because shared memory segments and the other IPC facilities (message queues and semaphores) are owned by *users*, not by *processes*, i.e. even if there are *no* processes using a certain IPC facility, one still does not know whether or not the facility can be safely removed. Only the designer/'manfacturer' of the applicable software knows that.

[harry d brown jr]

Simon,

take a look at this:

http://us-support.external.hp.com/cki/bin/doc.pl/sid=0826f7060eeca7ed78/screen=ckiDisplayDocument?docId=200000051528636

BUT, BE VERY CAREFUL, BECAUSE YOU CAN TOAST YOUR MACHINE!


live free or die
harry

[Sridhar Bhaskarla]

Simon,

I use ipcrm only when the applications that are using the IPC facilities are down but didn't release them. You basically do it when the application is down but still the facilities are shown up in ipcs.

Just cleaning them on the fly may cause lapses in the inter process communication and you may end up with jombies and defunct processes.

If resources are a problem give'em more. Or ask your application guys to fix their problems.

-Sri