<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: semaphor in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608085#M35455</link>
    <description>RajMan makes a very good point here.  Unless you can positively identify something you don't want to kill it.  &lt;BR /&gt;And let me add...unless you know what is running, and more importantly what and how it runs, don't kill.  Example:&lt;BR /&gt;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...&lt;BR /&gt;My point being...be sure of everything going on in the background, before you start killing something.&lt;BR /&gt;As RajMan said it is much easier to increase semmaphores...if you have the resources.&lt;BR /&gt;&lt;BR /&gt;Just a thought,&lt;BR /&gt;Rit</description>
    <pubDate>Tue, 06 Nov 2001 13:25:43 GMT</pubDate>
    <dc:creator>Rita C Workman</dc:creator>
    <dc:date>2001-11-06T13:25:43Z</dc:date>
    <item>
      <title>semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608083#M35453</link>
      <description>Hi ,All masters !&lt;BR /&gt;I work on HP-UX 11.0. I observed the fact that the number of semaphores of active interpro-&lt;BR /&gt;cess communication increases continually. The&lt;BR /&gt;third field of the gived rows by ipcs contains&lt;BR /&gt;a phzsical value.&lt;BR /&gt;I don't know identifier this adress with its&lt;BR /&gt;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. &lt;BR /&gt;When and wich conditions may I remove the unused rows endevoured the enhanced security.&lt;BR /&gt;I'd like to take advantage of ipcrm and manage this bottleneck.</description>
      <pubDate>Tue, 06 Nov 2001 11:56:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608083#M35453</guid>
      <dc:creator>SIMON  ; TAMÁS</dc:creator>
      <dc:date>2001-11-06T11:56:29Z</dc:date>
    </item>
    <item>
      <title>Re: semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608084#M35454</link>
      <description>&lt;BR /&gt;Hi,&lt;BR /&gt;&lt;BR /&gt;  If you are running out of semaphores on the system, then you would be better of increasing&lt;BR /&gt;the the number of semaphores (semmns) in&lt;BR /&gt;the kernel, rather than trying to release&lt;BR /&gt;semaphores using the ipcrm command.  &lt;BR /&gt;&lt;BR /&gt;   ipcrm command is used to release semaphores&lt;BR /&gt;which are not being used by any process,&lt;BR /&gt;i.e  the NATTCH should be 0 in the ipcs -as&lt;BR /&gt;command output.   Otherwise the results of&lt;BR /&gt;using the command will be unpredictable.&lt;BR /&gt;&lt;BR /&gt;-raj &lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 06 Nov 2001 12:57:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608084#M35454</guid>
      <dc:creator>Roger Baptiste</dc:creator>
      <dc:date>2001-11-06T12:57:25Z</dc:date>
    </item>
    <item>
      <title>Re: semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608085#M35455</link>
      <description>RajMan makes a very good point here.  Unless you can positively identify something you don't want to kill it.  &lt;BR /&gt;And let me add...unless you know what is running, and more importantly what and how it runs, don't kill.  Example:&lt;BR /&gt;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...&lt;BR /&gt;My point being...be sure of everything going on in the background, before you start killing something.&lt;BR /&gt;As RajMan said it is much easier to increase semmaphores...if you have the resources.&lt;BR /&gt;&lt;BR /&gt;Just a thought,&lt;BR /&gt;Rit</description>
      <pubDate>Tue, 06 Nov 2001 13:25:43 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608085#M35455</guid>
      <dc:creator>Rita C Workman</dc:creator>
      <dc:date>2001-11-06T13:25:43Z</dc:date>
    </item>
    <item>
      <title>Re: semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608086#M35456</link>
      <description>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.  &lt;BR /&gt;&lt;BR /&gt;If you remove the wrong semaphore, you could unleash hell, possibly corrupt your database, crash your system, toast your users, etc...&lt;BR /&gt;&lt;BR /&gt;live free or die&lt;BR /&gt;harry</description>
      <pubDate>Tue, 06 Nov 2001 13:30:43 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608086#M35456</guid>
      <dc:creator>harry d brown jr</dc:creator>
      <dc:date>2001-11-06T13:30:43Z</dc:date>
    </item>
    <item>
      <title>Re: semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608087#M35457</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;Run ipcs -moba&lt;BR /&gt;&lt;BR /&gt;look for the coloumn NATTACH with zero attachments. This semaphor can be be saftley killed by ipcrm -m followed by the number &lt;BR /&gt;&lt;BR /&gt;Goodluck&lt;BR /&gt;-USA..</description>
      <pubDate>Tue, 06 Nov 2001 14:35:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608087#M35457</guid>
      <dc:creator>Uday_S_Ankolekar</dc:creator>
      <dc:date>2001-11-06T14:35:19Z</dc:date>
    </item>
    <item>
      <title>Re: semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608088#M35458</link>
      <description>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.</description>
      <pubDate>Tue, 06 Nov 2001 15:33:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608088#M35458</guid>
      <dc:creator>Frank Slootweg</dc:creator>
      <dc:date>2001-11-06T15:33:46Z</dc:date>
    </item>
    <item>
      <title>Re: semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608089#M35459</link>
      <description>Simon,&lt;BR /&gt;&lt;BR /&gt;take a look at this:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://us-support.external.hp.com/cki/bin/doc.pl/sid=0826f7060eeca7ed78/screen=ckiDisplayDocument?docId=200000051528636" target="_blank"&gt;http://us-support.external.hp.com/cki/bin/doc.pl/sid=0826f7060eeca7ed78/screen=ckiDisplayDocument?docId=200000051528636&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;BUT, BE VERY CAREFUL, BECAUSE YOU CAN TOAST YOUR MACHINE!&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;live free or die&lt;BR /&gt;harry</description>
      <pubDate>Tue, 06 Nov 2001 16:50:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608089#M35459</guid>
      <dc:creator>harry d brown jr</dc:creator>
      <dc:date>2001-11-06T16:50:06Z</dc:date>
    </item>
    <item>
      <title>Re: semaphor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608090#M35460</link>
      <description>Simon,&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Just cleaning them on the fly may cause lapses in the inter process communication and  you may end up with jombies and defunct processes.&lt;BR /&gt;&lt;BR /&gt;If resources are a problem give'em more. Or ask your application guys to fix their problems.&lt;BR /&gt;&lt;BR /&gt;-Sri</description>
      <pubDate>Tue, 06 Nov 2001 17:01:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/semaphor/m-p/2608090#M35460</guid>
      <dc:creator>Sridhar Bhaskarla</dc:creator>
      <dc:date>2001-11-06T17:01:20Z</dc:date>
    </item>
  </channel>
</rss>

