Re: trouble with custom signal handlers

I couldn't reproduce the error you showed with your example code. I tried:

use warnings;
use strict;

sub handleSigs {
    my ($signalReceived) = @_;
    my $exitVal = 0;
    warn("warning: received $signalReceived signal");
    if ($signalReceived eq "INT") { $exitVal = 1; }
    elsif ($signalReceived eq "USR1") { $exitVal = 2; }
    elsif ($signalReceived eq "USR2") { $exitVal = 3; }
    exit($exitVal);
}

$SIG{USR1}=\&handleSigs;
$SIG{USR2}=\&handleSigs;
print "My PID is $$\n";
sleep(10);
print "Exiting\n";
[download]

And when I send a SIGUSR1 or SIGUSR2, I got the expected message warning: received USR1 signal at ....

I'm guessing there's some part of your code that is relevant to the problem that you haven't shown. If you could try to boil down your code to something that reproduces the problem, that would be very helpful. See also Short, Self Contained, Correct Example

Regards,
-- Hauke D

Comment on Re: trouble with custom signal handlers Select or Download Code

Replies are listed 'Best First'.
Re: trouble with custom signal handlers by casaschi (Novice) on Apr 17, 2016 at 11:22 UTC
@haukex: thanks for looking into this. The application is few hundred lines long, so definitely something elsewhere might have an impact, however I could not easily isolate the issue. Any suggestion how to approach debugging this. Also, could the delayed signal issue (see safe/unsafe signal) result in the error message about the missing signal handler? Anything else that could de-register a signal handler?	[reply]
Re^2: trouble with custom signal handlers by afoken (Chancellor) on Apr 17, 2016 at 12:01 UTC
Anything else that could de-register a signal handler? Usually, signal handlers are set and unset by assigning to %SIG, so start looking for assignments to `%SIG`. A text search for "`SIG`" should be sufficient. XS code can mess with signals behind your back, and without perl noticing it. If you use XS code, search for signal and sigaction in the XS code. The POSIX module also implements a wrapper for sigaction, so you may also want to search for sigaction in the perl code. And the most obvious one: Search for the constant part of the error message ("received, but no signal handler set.") in the code. A quick CPAN search reveals that the message may actually come from within perl, from the thread handling or the magic handling code. However, perldiag does not document this message. So, it looks to me like you have really messed up perl's internals. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^2: trouble with custom signal handlers by BrowserUk (Patriarch) on Apr 17, 2016 at 12:08 UTC
Any suggestion how to approach debugging this. Is it possible that you're calling a module that implements its own local signal handling for something and instead of restoring what was there previously, it just sets them to undef? 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". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]