Re: signal handling in exec()'d code

You may be doing something wrong in the code you're not showing us. This works on my machine:

use strict;
use warnings;

$SIG{INT} = sub { print "caught SIGINT\n"; exit };

sleep 1;
exec $^X, $0;
[download]

When I run this, wait a few seconds and send press Ctrl+C I get the "caught SIGINT" message, so the re-installing of the signal handler worked.

Perl 6 - links to (nearly) everything that is Perl 6.

Comment on Re: signal handling in exec()'d code Download Code

Replies are listed 'Best First'.
Re^2: signal handling in exec()'d code by jliv (Initiate) on Jan 25, 2010 at 12:33 UTC
I can confirm that your example above works for me here on my local machine as well (Fedora 12). Here's some more info about my setup: The top-level program sets its own process group (0) and invokes setsid so that it can take down all subprocesses if and when an INT is received. Depending on the code being run, it makes use of backticks, system() and fork(), so there will always be some sort of process tree at any given moment. Other than setting the signal handler I mentioned above, there is no other signal modification anywhere in the code. Here is an example. The top-level program is called client.pl. Here is the output of pstree -p: `bash(1274)---client.pl(16775)---client.pl(7703)---sh(7704)---binary_release_12(7705)` In this case, the code has forked itself and invoked an external binary. The terminal in which process 16775 was launched doesn't respond to a Ctrl-C since that process exec()d itself about 20 mins ago. If you guys have any other ideas of what could be fouling me up, let me know. Thanks in advance for the help!	[reply] [d/l]
Re^3: signal handling in exec()'d code by jethro (Monsignor) on Jan 25, 2010 at 13:41 UTC
The man page of setsid: "The calling process... has no controlling tty". Wouldn't that defeat a Ctrl-C signal getting through?	[reply]
Re^4: signal handling in exec()'d code by jliv (Initiate) on Jan 25, 2010 at 14:38 UTC
I will try removing it and see what I get and let you guys know. This did cross my mind, but since I invoke setsid() right before the signal handler and since the signal handler works fine before exec(), I determined that setsid shouldn't affect what I am seeing. After exec(), the new process should inherit the same process space as the previous process, and since setsid() didn't prevent SIGINT from being caught in the initial process, I figured it shouldn't affect any subsequent exec()d processes. Am I mistaken here?	[reply]