There is a "bug" in the signal handling part of the tang code (at least in some environments) which causes the SIGCHLD signal handler not being invoked after the first request. It seems like the signal handler is reset after the first time it is called.
Here's how I'm running the daemon
[sudo] password for pphilip:
Listening on 0.0.0.0:9090
Listening on [::]:9090
you can see 2 defunct processes because the first child was reaped by the signal handler
I couldn't find out exactly why this was happening, but according to the man page of signal(2):
The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
There are two solutions to the problem:
Reinstall the signal handler at the end of the signal handler call
Use sigaction instead
I have verified that both the methods eliminates this problem on my platform. But I prefer the second option because it is supposed to be more portable, unless there is some concern about non-linux platforms.
There is a "bug" in the signal handling part of the tang code (at least in some environments) which causes the SIGCHLD signal handler not being invoked after the first request. It seems like the signal handler is reset after the first time it is called. Here's how I'm running the daemon
Here's the process list after 3 curl requests
you can see 2 defunct processes because the first child was reaped by the signal handler
I couldn't find out exactly why this was happening, but according to the man page of signal(2):
The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
There are two solutions to the problem:
sigaction
insteadI have verified that both the methods eliminates this problem on my platform. But I prefer the second option because it is supposed to be more portable, unless there is some concern about non-linux platforms.
PR #110 opened to address this issue -PP