in reply to Re^5: SIGHUP delivered on Windows
in thread SIGHUP delivered on Windows

Searching our code, I find exactly one place where we possibly invoke a SIGHUP handler, but I can't see how this could apply to my case. Maybe I'm overlooking something - could you have a look at the code below? This is the code we execute right after the start of our program, within an INIT block:

foreach my $signame (split(' ', $Config{sig_name})) { if ($signum) { $SIG{$signame} = $signame =~ /^KILL|STOP$/ ? 'IGNORE' # According to perldoc perlipc, they + can be ignored, but not trapped : sub { $SIG{$signame} = 'DEFAULT'; print {$_} "\n\nCaught signal $signame at ", timestampHMS, "\nCalled from:\n", callchai +n(3, 16), "\n\n" for (shutdown_log_handle(), *STDOUT); # We need a special handler for INT (i.e. cont +rol-C from command line), because # the default action would not call the END ha +ndlers and hence not unregister # the instance in the database. For other inte +rrupts, we deliberatrely do NOT # want it unregistered if ($signame eq 'INT') { print {$_} "Turning into graceful exit\n" for (shutdown_log_handle(), *STDOUT); exit; } else { kill($signum, $$); # proceed with norma +l handling of signal } }; } ++$signum; }
In our case, the logfiles only show the line saying a SIGHUP was received. As you can see, we *do* have a kill in this code, but it would simply rethrow the same signal.

However, there *is* some processing going on after we receive a signal. Before outputting the line to our logfile, we invoke for example the functions timestampHMS (to format the time in a nice way) and callchain (which formats a stacktrace using the Perl standard function caller</c>. While none of these functions explicitly send a signal, could it be that an exception occuring within this signal handler (or a second signal arriving by that time) could be translated somehow into a SIGHUP?

Ronald Fischer <>