Would "something" fit, for instance, a process which started our Perl process, and then delivered a Windows Message to this process, and Perl, not knowing what to do with this message, invokes the signal handler established for SIGHUP? In our case, the parent process would be Console2 (a sourceforge application which hosts several DOS Console session in parallel), so this might be a possible culprit...

Would "something" fit, for instance, a process [ Console2 ] which started our Perl process, and then delivered a Windows Message to this process, and Perl, not knowing what to do with this message, invokes the signal handler established for SIGHUP?

No. I downloaded the source for console2 and the string "SIGHUP" does not appear anywhere in it, so your log message does not come from that.

As I said, I don't believe there is any way for a perl process to ever invoke a SIGHUP handler. Which only leaves your perl script to be the source of that log message in response to some stimulus other than a sighup. (ie. user error)

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

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;
        }
[download]

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 <ynnor@mm.st>