in reply to Re: No child processes - system limit?
in thread No child processes - system limit?

Well, the reason I'm thinking resource limit is that this only occurs when busy, and then a couple of seconds later it works fine again.

The docs for select indicate that this is the select(2) system call, but the docs for that say the following:

...On error, -1 is returned, and errno is set appropriately;...

and lists the following errors:
    An invalid file descriptor was given in one of the sets. (Perhaps a file descriptor that was already closed, or one on which an error has occurred.)
    A signal was caught; see signal(7).
    nfds is negative or the value contained within timeout is invalid.
    unable to allocate memory for internal tables.
... none of which correspond to the no child processes, and leaving me at a bit of a loss

Replies are listed 'Best First'.
Re^3: No child processes - system limit?
by almut (Canon) on Apr 01, 2010 at 14:26 UTC

    What do you get for

    $ getconf CHILD_MAX

    (or getconf -a, just in case...)

      for getconf CHILD_MAX i get: 27968

      for getconf -a

      any of these mean anything to you?

        27968 seems large enough... (or do you really have that many processes?)

        On some older linux systems, this is set to 999, which is somewhat closer to potentially becoming a problem. (BTW, this value does not necessarily correspond to what is reported by ulimit — which is why I asked.)

        The other cause for a fork to fail is insufficient memory (presuming the "waiting for a non-existent child"-theory I mentioned above).  So, is the memory usage actually close to the limit when the problem occurs?

        I'll take a closer look at the other conf settings to see if anything jumps out at me (not that I would know what every single one of them means... :)