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

I have a question concerning how to regain control after issueing a system command to start another program. The other program, called MEVS, both must run 24/7. The perl program is a bandaid that looks to see if MEVS is running and, if not, then it starts it up. The bandaid is a perl module while MEVS is a large system written in C++. My problem is that control never comes back. I looked at the process ids and the new program was running okay, however, MEVs had the parent pid which belonged to the bandaid module that issued the system command to start it. Cancelling the bandaid.pl program also cancels the MEVS program. It looks like the bandaid module was waiting for a response or for the new process to finish before control would return. Do I need to create a fork and then an exec? I thought that was what the system command was for? The two commands following the system command never get executed.
$version = "test"; $pid = get_pid($version); if ( $pid eq "" ) # if null, MEVS not running - issue comma +nd to start MEVS { @command = ("/mevs/$version/bin/mevs", "/mevs/$version/data/con +fig_data/mevs2.cfg", "online", "&"); system(@command); # restart MEVS $pid = get_pid($version); # Get the new pid print "new pid: [$pid]\n"; # print pid . . . ###################################################################### +###### sub get_pid ###################################################################### +###### { my $version = $_[0]; # passed version, prod/test/qa my $command = sprintf q(ps -ef | grep %s | grep online | awk '{pri +nt $2}'), $version; # create get pid command my @output = `$command`; # get the pid(s) return $output[0]; # return new pid + }
Thanks for all your help.

Replies are listed 'Best First'.
Re: Creating External Processes without losing control
by samtregar (Abbot) on Dec 01, 2004 at 21:29 UTC
    If you add an ampersand after the command system() will fork off the process for you and return immediately. However, before you do anything more you should read perlipc. There's a lot of good information there that applies to the kind of script you're writing. If you have questions after reading it come back and ask them here.

    UPDATE: You might also want to take a look at PSMON. If you can't use it directly I'm sure you could learn a lot from reading the source. It's a Perl script which monitors processes and takes actions based on configurable rules.

    -sam

      Depends on the shell
        What does?

        -sam

Re: Creating External Processes without losing control
by edan (Curate) on Dec 02, 2004 at 13:41 UTC

    fork and exec is definitely the way to go. As mentioned, perlipc will tell you how. Here's a basic fork/exec to get you going:

    my @command = qw( /mevs/$version/bin/mevs /mevs/$version/data/config_data/mevs2.cfg online ); $SIG{CHLD} = 'IGNORE'; defined(my $pid = fork) or die "Can't fork ($!)"; if ( $pid ) { # child exec @command or die "Can't exec ($!)"; } # parent continues... print "new pid: [$pid]\n"; # print pid
    --
    edan

Re: Creating External Processes without losing control
by zentara (Cardinal) on Dec 02, 2004 at 14:05 UTC
    IPC::Open3 gives you the most control over the external process. You can monitor the stdout,stderr, and send to it via stdin. You get it's pid, so you can kill and restart it. If you need interaction with the exteranl process IPC::Open3 is the way to go. It will "fork and exec" your program, and automatically setup pipes to talk to it.

    I'm not really a human, but I play one on earth. flash japh
Re: Creating External Processes without losing control
by bprew (Monk) on Dec 01, 2004 at 22:54 UTC
    I was under the impression that doing an "exec" would simply start the process and leave it. By not waiting for a return value, you should be able to continue processing. Unfortunately, I don't generally do a whole lot with system and exec calls, but perlipc (perldoc perlipc) does :) Thanks

    --
    Ben
    "Naked I came from my mother's womb, and naked I will depart."

      exec does not start a new process. exec replaces the current process with a new process executing the given executable. A successful exec will never return, as the original process's code is no longer executing. exec is often combined with fork to split off a child process and cause that process to execute the given executable.