gflohr
commented
4 years ago This is the code snippet that spawns the child process:
if ($self->{__daemonize}) {
if (fork) {
CORE::exit(0);
}
unless (POSIX::setsid()) {
# make child session leader and detach from terminal
die "Unable to detach process\n";
}
## Close open file descriptors.
POSIX::close($_) foreach open_files;
## Reopen stdin to /dev/null
open(STDIN, "+>/dev/null")
or warn "Cannot redirect standard input to /dev/null: $!\n";
# XXX
# Re-opening STDOUT colides with it being tie-ed during the request.
# open(STDOUT, "+>/dev/null")
# or warn "Cannot redirect standard output to /dev/null: $!\n";
# Re-opening STDERR colides with mod_perl.
# open(STDERR, "+>/dev/null")
# or warn "Cannot redirect standard error to /dev/null: $!\n";
}
exec($self->{__path}, @{$self->{__argv}})
or die "Exec failed: " . $!;The function open_files() returns a list of open file descriptors $self->{__path} is the path to the script to be executed, $self->{__argv} is the list of arguments.
jkeenan
iabyn
tonycoz
Module:
Description
In a web server based on
Net::Server(version 2.007 and the most recent 2.009) with theNet::Server::Singlepersonality, I get the error "Signal SIGCHLD received, but no signal handler set." and the server terminates. When using theNet::Server::PreForkpersonality, the signal is SIGHUP instead of SIGCHLD, and the server continues to run because only one of the forked children had terminated.The error occurs after a handler of the server has forked a background process. In the child,
POSIX::setsid()is called, all open file descriptors are closed andSTDINis redirected to/dev/null.STDOUTandSTDERRare not re-opened because the same code is supposed to work in a mod_perl environment.%SIGis not modified. The child process (another Perl script) is executed withexec().There is a corresponding question on stackoverflow.com: https://stackoverflow.com/questions/60708194/error-message-signal-sigchld-received-but-no-signal-handler-set/60761593#60761593
I have answered it myself with additional findings/information: https://stackoverflow.com/a/60761593/5464233
My workaround is to explicitely assign "DEFAULT" to
$SIG{CHLD}resp.$SIG{HUP}, instead of the old valueundefbut that is not a satisfying solution. That is very similar to the workaround that was recommended for an almost identical problem in GNU parallel several years ago: https://lists.gnu.org/archive/html/bug-parallel/2016-10/msg00000.htmlSteps to Reproduce
Not possible. It's a (proprietary) application with 350000+ lines of Perl code. Modifying the code or running the application in the Perl debugger makes the error disappear instantly. If there is interest in trying to debug the problem, I can provide access to a test installation.
I also wasn't able to run the program in
gdbbecause the server did not come up.Expected behavior
The script should not be able to make the interpreter terminate prematurely.
Perl configuration
I have tested on Mac OS X with these Perl versions using perlbrew:
All versions starting from 5.18.4 have the problem. The older ones do not have it.
The same behavior was reported for 5.26.x to 5.30.x on Linux.