<?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 Too many semaphores! in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421641#M166</link>
    <description>I'm running on HP-UX 11.0 and I recently installed CiscoWorks2000 products. &lt;BR /&gt;Since then, and when I start CiscoWorks daemons, the semaphore table (semmni) &lt;BR /&gt;begins to grow until it reaches almost the upper limit (in my case 4096). I &lt;BR /&gt;thought it was a bug from the operating system, so I installed PHKL_20901, a &lt;BR /&gt;fix that exists for semget().&lt;BR /&gt;&lt;BR /&gt;If I run ipcs -s, all the semaphores uncorrectly allocated have the form:&lt;BR /&gt;&lt;BR /&gt;s133779480 0x00000000 --ra-ra-ra-       bin       bin&lt;BR /&gt;&lt;BR /&gt;(bin is the user for CiscoWorks processes).&lt;BR /&gt;&lt;BR /&gt;Should I blame Cisco, HP or myself?&lt;BR /&gt;&lt;BR /&gt;Any suggestion would really be appreciated.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Jesus.</description>
    <pubDate>Mon, 17 Apr 2000 07:25:52 GMT</pubDate>
    <dc:creator>Jesus m. Charro</dc:creator>
    <dc:date>2000-04-17T07:25:52Z</dc:date>
    <item>
      <title>Too many semaphores!</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421641#M166</link>
      <description>I'm running on HP-UX 11.0 and I recently installed CiscoWorks2000 products. &lt;BR /&gt;Since then, and when I start CiscoWorks daemons, the semaphore table (semmni) &lt;BR /&gt;begins to grow until it reaches almost the upper limit (in my case 4096). I &lt;BR /&gt;thought it was a bug from the operating system, so I installed PHKL_20901, a &lt;BR /&gt;fix that exists for semget().&lt;BR /&gt;&lt;BR /&gt;If I run ipcs -s, all the semaphores uncorrectly allocated have the form:&lt;BR /&gt;&lt;BR /&gt;s133779480 0x00000000 --ra-ra-ra-       bin       bin&lt;BR /&gt;&lt;BR /&gt;(bin is the user for CiscoWorks processes).&lt;BR /&gt;&lt;BR /&gt;Should I blame Cisco, HP or myself?&lt;BR /&gt;&lt;BR /&gt;Any suggestion would really be appreciated.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Jesus.</description>
      <pubDate>Mon, 17 Apr 2000 07:25:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421641#M166</guid>
      <dc:creator>Jesus m. Charro</dc:creator>
      <dc:date>2000-04-17T07:25:52Z</dc:date>
    </item>
    <item>
      <title>Re: Too many semaphores!</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421642#M167</link>
      <description>It may just be a matter of increasing the semaphore kernel parameters to allow &lt;BR /&gt;for additional semaphores.  If the programs needs as many as it is allocating, &lt;BR /&gt;there's really no way around it.  &lt;BR /&gt;&lt;BR /&gt;Looking at the uid/gid on the semaphore (bin/bin in this case) doesn't &lt;BR /&gt;necessarily indicate the semaphore was created by the CiscoWorks program, only &lt;BR /&gt;that the program that created the semaphore had that uid and gid.</description>
      <pubDate>Mon, 17 Apr 2000 08:23:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421642#M167</guid>
      <dc:creator>Evan Day_1</dc:creator>
      <dc:date>2000-04-17T08:23:48Z</dc:date>
    </item>
    <item>
      <title>Re: Too many semaphores!</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421643#M168</link>
      <description>Thanks for your answer, Evan.&lt;BR /&gt;&lt;BR /&gt;The problem is that we have already increased the number of semaphores up to &lt;BR /&gt;4096. It doesn't matter how many semaphores we have, CiscoWorks2000 processes &lt;BR /&gt;(maybe JRE...) lock almost every semaphore available (4092 is usually the upper &lt;BR /&gt;limit).&lt;BR /&gt;&lt;BR /&gt;We have isolated the problem to Cisco processes simply because when the daemons &lt;BR /&gt;are stopped, the semaphore table does not grow much more than 100 semaphores, &lt;BR /&gt;and when we start the daemons, the number of semaphores begin to grow rapidly.&lt;BR /&gt;&lt;BR /&gt;I will try to patch JRE. Nobody with this same problem?&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Jesus.</description>
      <pubDate>Mon, 17 Apr 2000 23:34:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421643#M168</guid>
      <dc:creator>Jesus m. Charro</dc:creator>
      <dc:date>2000-04-17T23:34:26Z</dc:date>
    </item>
    <item>
      <title>Re: Too many semaphores!</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421644#M169</link>
      <description>Hi, There have been issues with Ciscoworks and the semaphores being used up.  Since you have already bumped up the parameters in HP, Check the PRs with Cisco, as this had been documented for solaris based machines as well, and can only assume that Cisco is working on a patch, or new release.</description>
      <pubDate>Fri, 16 Jun 2000 13:08:05 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421644#M169</guid>
      <dc:creator>William Ringler</dc:creator>
      <dc:date>2000-06-16T13:08:05Z</dc:date>
    </item>
    <item>
      <title>Re: Too many semaphores!</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421645#M170</link>
      <description>I've seen reports of this : &lt;BR /&gt;&lt;BR /&gt;there's a bug with Cisco-Works that if it's data is&lt;BR /&gt;corrupted it gets into a loop and sucks up all the semaphores...&lt;BR /&gt;So no matter how much you increased semmni/semmns&lt;BR /&gt;ciscoworks would have taken all the semaphores in its corrupted state.&lt;BR /&gt;&lt;BR /&gt;Bottom Line: CicsoWorks can become corrupt and take up all available&lt;BR /&gt;semaphores in a loop, thereby causing other applications such as ITO to&lt;BR /&gt;fail with "semget(2) failed - no space left on device"&lt;BR /&gt;&lt;BR /&gt;Check with cisco support .. probably a patch by now</description>
      <pubDate>Fri, 16 Jun 2000 13:10:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421645#M170</guid>
      <dc:creator>Alex Glennie</dc:creator>
      <dc:date>2000-06-16T13:10:39Z</dc:date>
    </item>
    <item>
      <title>Re: Too many semaphores!</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421646#M171</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;You can release the semaphores by killing the ones genereated by the cisco works process with this command:&lt;BR /&gt;&lt;BR /&gt;ipcrm -s SID (semaphore ID) &lt;BR /&gt;For example: ipcrm -s 133779480&lt;BR /&gt;&lt;BR /&gt;Cheers!&lt;BR /&gt;</description>
      <pubDate>Fri, 16 Jun 2000 13:30:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421646#M171</guid>
      <dc:creator>CHRIS_ANORUO</dc:creator>
      <dc:date>2000-06-16T13:30:59Z</dc:date>
    </item>
    <item>
      <title>Re: Too many semaphores!</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421647#M172</link>
      <description>Hello Jesus,&lt;BR /&gt;&lt;BR /&gt;Are you still having the same problem?&lt;BR /&gt;&lt;BR /&gt;Chris&lt;BR /&gt;</description>
      <pubDate>Mon, 17 Jul 2000 13:03:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/too-many-semaphores/m-p/2421647#M172</guid>
      <dc:creator>CHRIS_ANORUO</dc:creator>
      <dc:date>2000-07-17T13:03:42Z</dc:date>
    </item>
  </channel>
</rss>

