in reply to Mysterious bad file descriptor after fork

It's somewhat hard to tell without the full context ...  but just one idea to get the discussion going :)   Are you checking the return value of the accept() call?  In some circumstances, accept may return undef (without having gotten any connection attempt, that is). In case of EINTR ($! eq "Interrupted system call") you just have to call accept again. This is more of an issue on some platforms (e.g. AIX) than on others (Linux), because some may automatically resume interrupted system calls — but in case of doubt, be prepared to handle it yourself...   (Google for '"interrupted system call" EINTR accept' (or some such) for more background.)

In any case, what I just said would only make sense if the problem is occurring sporadically (I'm not quite sure how to read your "Under certain circumstances"). If it reproducibly occurs with DBConnect_not_ok, then something else will likely be the problem ...

Replies are listed 'Best First'.
Re^2: Mysterious bad file descriptor after fork
by gnork (Scribe) on Jul 10, 2007 at 19:39 UTC
    "Certain circumstances" refers to calling DBConnect_no_ok instead of DBConnect_ok before server start. I edited my post to better reflect that.

    I will look into the return value of accept().

    Thanks for the hint, will report back.

    cat /dev/world | perl -e "(/(^.*? \?) 42\!/) && (print $1))"
    errors->(c)
      The return value of accept() is now checked and properly treated. The error persists, so it was not the root of the evil.

      Best rgds
      gnork

      cat /dev/world | perl -e "(/(^.*? \?) 42\!/) && (print $1))"
      errors->(c)