Check it out - especially the documention which gives an excellent receipe for writing a robust daemon application.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

And have you looked at "Complete Dissociation of Child from Parent" in perlipc?

Updated link - fixed bad cut n paste job :-)

To provide a bit more detail:

system("nohup xterm&");

should "run a command immune to hangups, with output to a non-tty"

Joe.

#!/usr/bin/perl -w

use strict;

my $pid = fork();
if ($pid == 0)
{
        # This is the child process.
        # exec() the external program.
        exec("my_program")
            or die "could not exec my_program: $!";
}
elsif (!defined($pid))
{
        die "could not fork";
}

# Everything below here is the parent process
print "This is the parent process\n";
[download]

-Matt

Thanks,


Unfortunately that doesn't work. As soon as the main program (the one that did the forking) finishes running, the child process (the one that got forked) gets reaped.

I even tried modifying that code slightly to incorporate the previous suggestion of using Proc::Daemon::init. It doesn't matter, the child still dies. Is it possible that this is simply something that can only be done in sh and not in Perl?

Here is my test code (based on your suggestion):
a.pl :

#!/usr/local/bin/perl
      my $pid = fork();
      if ($pid == 0)
      {
              # This is the child process.
              # exec() the external program.
              exec("./b.pl &")
                  or die "could not exec my_program: $!";
      }
      elsif (!defined($pid))
      {
              die "could not fork";
      }

      # Everything below here is the parent process
      print "This is the parent process\n";
[download]

b.pl:


#!/usr/local/bin/perl
use Proc::Daemon;
Proc::Daemon::init;

open ( OUT, ">b.out" );
while ( 1 ) {
    print OUT `/bin/date`;
    sleep( 2 );
}
[download]

I found that a.pl is calling b.pl, which is outputing the present time to b.out. But then, a.pl exits out, and so does b.pl. This is not the desired result. By the way, I'm doing this on FreeBSD 4.1.1 if that makes any difference.

Here's the test code I used:

#!/usr/bin/perl -w
# forker.pl

use strict;

my $pid = fork();
if ($pid == 0)
{
        exec("/tmp/busy_wait.pl");
}
elsif (!defined($pid))
{
        die "could not fork";
}

print "This is the parent process\n";
[download]

#!/usr/bin/perl -l
# busy_wait.pl

while (1)
{
        print "Busy!";
        sleep 2;
}
[download]

When I execute forker.pl, I get this output:

[matt@megatron ~]$ /tmp/forker.pl
Busy!
This is the parent process
[matt@megatron ~]$ Busy!
Busy!
Busy!
[download]

The parent dies, and I get my shell prompt back, but the busy_wait.pl child lives on until I purposefully kill it.

-Matt

#!/usr/bin/perl -w
use strict;
use POSIX qw{setsid};
### or just 'use POSIX;' if you plan to use other
### functions from it, of course

if ( fork ) {
    {
        ### grandparent code goes here
        print "My grandkid should do a cute l'il ls...\n";
    } 
    exit; ### die if we're the parent
}
if ( fork ) {
    exit; ### die if we're the parent of this one, too.
}
### grandchild code starts here
POSIX::setsid; ### should be part of a new session now
exec '/bin/ls', '.';
[download]

Don't forget to close STDIN, STDOUT and STDERR, and change pwd to "/" so you don't end up with a background process keeping you from unmounting some filesystem later on. I use the following at daemon start time.

my $pid = fork();

if($pid != 0){
    exit 0;
}

chdir "/";

close STDOUT;
close STDERR;
close STDIN;

POSIX::setsid();   # this takes care of controlling terminals
[download]

Stevens covered this pretty well, I think it was "Advanced Programming in the UNIX Environment" or some such.

Try exec:

"This function terminates the currently running Perl script by executing another program in place of itself."

----Asim, known to some as Woodrow.

Thanks, but I don't want to exec.. my Perl script has other things that it needs to do. Some times I want to be able to start other processes up at the same time. This is mainly needed in a CGI environment, but not just for CGI.

perlipc has some stuff you may want to try :


Complete Dissociation of Child from Parent

In some cases (starting server processes, for instance) you'll want to
+ complete dissociate the child process from the parent. The easiest w
+ay is to use:

use POSIX qw(setsid);
    setsid()            or die "Can't start a new session: $!";

However, you may not be on POSIX. The following process is reported to
+ work on most Unixish systems. Non-Unix users should check their Your
+_OS::Process module for other solutions.

    * Open /dev/tty and use the TIOCNOTTY ioctl on it. See tty(4) for 
+details.

    * Change directory to /

    * Reopen STDIN, STDOUT, and STDERR so they're not connected to the
+ old tty.

    * Background yourself like this:

fork && exit;

    * Ignore hangup signals in case you're running on a shell that doe
+sn't automatically no-hup you:

$SIG{HUP} = 'IGNORE';       # or whatever you'd like
[download]

---

The docs are a little different than an eariler version I found on the Net, so give it a try and see if that solves your problem. If not, look at the perlipc manpage excerpted from the Activestate's Perl UNIX user's e-mail list for a longer program.

----Asim, known to some as Woodrow.

Edit: chipmunk 2001-11-08

do a fork(), then do an exec(). the exec() will only replace the fork()'ed child.

For a poor man's parallel process control you can modify this by specifying a random queue to send the job to. OK, pretty poor, but it is surprising how far this one goes.