<?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: Unexpected SIGCHLD in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/unexpected-sigchld/m-p/4015332#M96469</link>
    <description>The tusc trace provided me with exactly what I needed. I turned out that I hit the maxfiles kernel limit somewhere so I changed my piece of code that was the cause.&lt;BR /&gt;&lt;BR /&gt;What I still do not know why this causes a SIGCHLD. nice to find out but I'm happy already :-)&lt;BR /&gt;</description>
    <pubDate>Mon, 11 Jun 2007 01:05:44 GMT</pubDate>
    <dc:creator>Joost Bijen</dc:creator>
    <dc:date>2007-06-11T01:05:44Z</dc:date>
    <item>
      <title>Unexpected SIGCHLD</title>
      <link>https://community.hpe.com/t5/operating-system-linux/unexpected-sigchld/m-p/4015330#M96467</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;A program I wrote is started through inetd and handles input/output through stdin/stdout. It runs fine on my HP-UX 9000/800 single CPU box.&lt;BR /&gt;&lt;BR /&gt;When moving towards another 9000/800 with 4 CPU the program unexpectedly crashes and does so after receiving a SIGCHLD. Can it be that the difference is in the multiprocessor arrangement? The program on the first machine does not receive the SIGCHLD...&lt;BR /&gt;&lt;BR /&gt;I do not create children myself (in C that is...) but I have linked some BEA Tuxedo 8.1 libraries that may create threads that I am not aware of.&lt;BR /&gt;&lt;BR /&gt;Any hints on where to start looking for this behaviour?&lt;BR /&gt;&lt;BR /&gt;Thanks,&lt;BR /&gt;Joost&lt;BR /&gt;</description>
      <pubDate>Thu, 07 Jun 2007 08:08:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/unexpected-sigchld/m-p/4015330#M96467</guid>
      <dc:creator>Joost Bijen</dc:creator>
      <dc:date>2007-06-07T08:08:38Z</dc:date>
    </item>
    <item>
      <title>Re: Unexpected SIGCHLD</title>
      <link>https://community.hpe.com/t5/operating-system-linux/unexpected-sigchld/m-p/4015331#M96468</link>
      <description>I suspect that your single CPU box was working more or less by accident in that the real problem is timing related. Of course, without a stack trace or at least some tusc output, it's not possible to know what is wrong. The fix may be as simple as adding a signal handler for SIGCHLD.</description>
      <pubDate>Thu, 07 Jun 2007 09:04:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/unexpected-sigchld/m-p/4015331#M96468</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2007-06-07T09:04:27Z</dc:date>
    </item>
    <item>
      <title>Re: Unexpected SIGCHLD</title>
      <link>https://community.hpe.com/t5/operating-system-linux/unexpected-sigchld/m-p/4015332#M96469</link>
      <description>The tusc trace provided me with exactly what I needed. I turned out that I hit the maxfiles kernel limit somewhere so I changed my piece of code that was the cause.&lt;BR /&gt;&lt;BR /&gt;What I still do not know why this causes a SIGCHLD. nice to find out but I'm happy already :-)&lt;BR /&gt;</description>
      <pubDate>Mon, 11 Jun 2007 01:05:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/unexpected-sigchld/m-p/4015332#M96469</guid>
      <dc:creator>Joost Bijen</dc:creator>
      <dc:date>2007-06-11T01:05:44Z</dc:date>
    </item>
  </channel>
</rss>

