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

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.

Replies are listed 'Best First'.
Re: Re: Re: Re: Signals and subprocesses using fork, and system or exec.
by exussum0 (Vicar) on Aug 26, 2003 at 11:08 UTC
    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.

        Well, here's an interesting note. If i fork off only one child, this code works. Doing 2 or more, it won't.

        Note: I'm not managing sshd servers. I'm managing the ssh clients. I can prove that my child gets the signal but doesn't propogate outward properly.

        All in all, I guess ssh is ignoring me :( I've done it via pipe, open (popen), system, exec.. ssh just doesn't like me :\
        ----
        Play that funky music white boy..