exussum0 has asked for the wisdom of the Perl Monks concerning the following question:

Hi! So here I sit, befuddled with this little chunk of code. Consider it a learning experience in signals since I could prolly just find something in CPAN that is more robust.. but have yet to, to understand my faux pas.

I'm trying to maintain multiple virtual scp's of sorts. This allows for some neat administration tricks, when I need the logfile here, but it's somewhere else. This is the bare-bone version, without the continuing where I left off in terms of the last line retrieved. I know how to do that :)

I can start it up, kill a child process directly, and a new one will take its place. I can kill the shell process started by system (note, system() used to be exec(), but I flipflopped trying to get it to work), and have a new process start up. Problem is, if i do a kill -HUP of the main process, it kills the other perl processes fine, but not the processes started by system/exec. Hepl! (a cookie to those who get the hepl reference)

use strict; #Because `system' and backticks block `SIGINT' and #SIGQUIT', killing the program they're running #doesn't actually interrupt your program. $SIG{HUP} = \&shutdown; $SIG{CHLD} = 'IGNORE'; my %PIDPOOL = (); my $continue = 1; for( my $x = 1; $x < 3; $x++) { setupProcess( $x ); } while( $continue ) { my $pid = wait(); if( $pid > 0 ) { my $process = $PIDPOOL{ $pid }; print "Process $process destroyed...\n"; setupProcess( $process ); } } sub shutdown( ) { $continue = 0; foreach my $pid ( keys %PIDPOOL ) { kill "HUP", $pid; } print "Shutting down...\n"; while( ( my $pid = wait() ) != -1 ) { print "$pid killed on shutdown of parent process...\n" +; } } sub setupProcess( ) { my $process = shift; my $pid = fork(); if( $pid ) { $PIDPOOL{ $pid } = $process; } else { $SIG{HUP} = sub{ print "Killing ssh...\n"; kill "ABRT +", -$$; }; print "$process started...\n"; # replaceable with exec( ) or die(...) system( "/bin/sh -c 'ssh sporty\@tao \"tail -f t\" > +t$process'") or die($!); exit; } }

Replies are listed 'Best First'.
Re: Signals and subprocesses using fork, and system or exec.
by sgifford (Prior) on Aug 26, 2003 at 02:51 UTC
    I see a few problems.

    Your system command error checking is wrong; it should be something like:

    system("...") == 0 or die "...";
    Also, Perl will automatically add /bin/sh -c if it's necessary, so you don't have to do that.

    But I don't think that's your problem.

    I also don't think it's a good idea to use $SIG{CHLD} = 'IGNORE'; and wait() together.

    I don't think that's the problem, either.

    Your sub declarations have parentheses after them, which creates a prototype. This prototype looks incorrect, and Pel issues a warning under -w.

    And I don't think that's your problem either.

    The problem I think you're having is that signal handlers are cleared when you use exec, and if you use system then $$ is the PID of the Perl process waiting for system to finish, not SSH. If you use exec, your HUP signal handler is cleared when ssh starts. If you use system, you kill ABRT Perl, doing nothing to the ssh process.

    If you want to send an ABRT signal to ssh (and I think that's not the signal you want, since it usually causes a coredump), I think you should use exec in setupProcess, and send an ABRT signal in shutdown.

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

Re: Signals and subprocesses using fork, and system or exec.
by Zaxo (Archbishop) on Aug 26, 2003 at 06:39 UTC

    I think Net:SSH will ease your child processes. The quoting hell you have in your system call invites trouble. If you must use exec or system, the list form of arguments is to be commended.

    After Compline,
    Zaxo

      not particularly, since i need multiple processes if i were doing multiple reads at the same time --- Play that funky music white boy..
Re: Signals and subprocesses using fork, and system or exec.
by bobn (Chaplain) on Aug 27, 2003 at 01:16 UTC

    This seems to work, substitituting a find command for the ssh:

    use strict; use warnings; #Because `system' and backticks block `SIGINT' and #SIGQUIT', killing the program they're running #doesn't actually interrupt your program. $SIG{HUP} = \&shutdown; # $SIG{CHLD} = 'IGNORE'; # wait() doesn't see child die if this isn't +commented my %PIDPOOL = (); my $continue = 1; for( my $x = 1; $x < 3; $x++) { setupProcess( $x ); } while( $continue ) { my $pid = wait(); if( $pid > 0 ) { my $process = $PIDPOOL{ $pid }; print "Process $process ended...\n"; setupProcess( $process ); } } sub shutdown { $continue = 0; foreach my $pid ( keys %PIDPOOL ) { print "$pid\n"; kill 9, $pid; } print "Shutting down...\n"; while( ( my $pid = wait() ) != -1 ) { print "$pid killed on shutdown of parent process...\n" +; } } sub setupProcess { my $process = shift; my $pid = fork(); if( $pid ) { $PIDPOOL{ $pid } = $process; } else { print "$process, $pid started, ...\n"; close STDERR; # stop permission denied messages exec( q[find / -name ifconfig] ) or die($!); # exec( q[ssh bobn@trc1] ) or die($!); } }

    Previous poster's comment on use of $SIG{CHLD} = 'IGNORE' and wait were correct.

    When I use the ssh command shown, the individual ssh processes are not well killable, I assume because they are waiting for a password. I'm assuming you've set up 'RSA' authentication for your sessions.

    As shown, killing the individual find processes causes new ones to spawn. In fact, even when they end naturally, new ones are spawned. Killing the parent process with -HUP kills everything.

    --Bob Niederman, http://bob-n.com

    All code given here is UNTESTED unless otherwise stated.