Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re^6: SIGHUP delivered on Windows

by rovf (Priest)
on May 24, 2013 at 07:33 UTC ( #1035082=note: print w/replies, xml ) Need Help??

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 <>

Replies are listed 'Best First'.
Re^7: SIGHUP delivered on Windows
by BrowserUk (Pope) on May 24, 2013 at 11:09 UTC
    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?

    I cannot see how that could happen.

    Firstly, for you to get to the line where you do kill SIGHUP, $$, your process would have to have already received a SIGHUP; because you're just rethrowing it. But I am unaware of anything that would ever send you a SIGHUP.

    There is the vague possibility that another Perl process could be sending your process a SIGHUP; but as far as I'm aware, any attempt to do so would simply get translated into a SIGTERM.

    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.
    network sites:
      I agree with your reasoning. That's what I thought too.

      So for the time being, this has to remain a mystery. Thanks for taking the time to analyze my code.

      Ronald Fischer <>
        If you were running Cygwin Perl all your fav unix signals would work. But you claim to run ActivePerl so IDK what to say further.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1035082]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (None)
    As of 2021-10-16 09:32 GMT
    Find Nodes?
      Voting Booth?
      My first memorable Perl project was:

      Results (69 votes). Check out past polls.