in reply to Re: Signals and subprocesses using fork, and system or exec.
in thread Signals and subprocesses using fork, and system or exec.

Switching to exec leaves ssh processes aboot. Though ... it does get rid of the "sh -c ssh". But from bash or tcsh, if you throw anything besides QUIT or TERM, it is supposed to get propogated.
I've tried to make a process group, but that fails just as bad :(
--
Play that funky music white boy..
  • Comment on Re: Re: Signals and subprocesses using fork, and system or exec.

Replies are listed 'Best First'.
Re: Re: Re: Signals and subprocesses using fork, and system or exec.
by sgifford (Prior) on Aug 26, 2003 at 07:24 UTC
    I suggest that you use a second fork(), and then exec in the child process of that fork. Something like this in setupProcess:
    #!/usr/bin/perl -w use strict; my $sshpid = fork(); defined($sshpid) or die "fork error: $!"; if ($sshpid) { print "Parent PID is $$\n"; # Parent $SIG{HUP} = sub { warn "Aborting ssh pid $sshpid\n"; kill 'ABRT', $sshpid; exit(1); }; wait; exit(0); } else { # Child exec '/bin/sleep 6' or die "exec error: $!"; }

    I'm using an ABRT signal because that's what you used; I still don't think it's the right signal for this purpose, although I'm not sure what is if you can't use TERM.

      I'm not quite sure what you are accomplishing by second fork.
      --
      Play that funky music white boy..

        The second fork lets you have two processes: one to run ssh, and the other to catch a HUP signal and do whatever it likes to the ssh server. The problem with your existing code is that when you run exec, the signal handler is cleared; using fork too lets you have one process with a signal handler of your choice, and a second process running ssh.

        I'm not sure that this has an advantage over not doing the second fork and just keeping the PID's that ran exec in %PIDPOOL.