I found that SIGCHLD can be delivered to the parent even while it's still blocked. It makes no sense but I am pretty sure that's what's happening. If the child finishes fast enough, the parent does the signal handler before getting to create the forker entry, so later on it blocks on sem_wait forever.

That's why the problem is easily reproducible with "/bin/true" or any non-existent path, but not with "/bin/sleep 0.01" (for example).

I can't reproduce this in a standalone program without threads, so I am guessing threads have something to do with this.

Hmm.

--
L.C. (Laurentiu C. Badea)

Alan DeKok wrote:
"L.C. (Laurentiu C. Badea)" <[EMAIL PROTECTED]> wrote:

With Red Hat 9 and the 2.4.20-8 kernel it does the same thing (same
freeradius as before but rebuilt for RH 9 from the src.rpm). So it
seems that a wider range of kernels is affected. Tried on a dual cpu
machine with both smp and up kernels to make sure.

Do you have any pointers as to what this bug is, or what kernel versions contain the fix ?


  Search the list archives.  I don't recall much more than that.


I suppose outside of getting a "fixed" kernel, there really isn't
another way to overcome this problem ?


  Run the server in single-threading mode.

  Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to