How do I run a script in the background? How should I run a script as daemon?

[jeroenes]

These are related questions. I asked the first question in the node Exec'd perl running wild on cpu-time.

Originally posted as a Categorized Question.

[jeroenes]

If you run a script in a the background with exec, things go nasty after a while when you kill your terminal. You can prevent this (I tried it only under linux) by setting SIG{INT}='IGNORE'.

Actually, a better solution is the Proc::daemon module, or the Net::daemon module if you need to claim a socket.

[Fastolfe]

If you disassociate the process from its parent (via setsid), this won't happen. When you kill your terminal (or exit it any way other than by typing "exit" or "logout"), a HUP signal is sent to the terminal's process group. This means every process that currently is in the shell's process group receives the HUP signal, which effectively kills everything started during that shell session.

The approved way of disassociating a process from its process group is by changing its process group ID (pgid), such as via setsid. See perlipc and my other comment at Re: Is it possible to background a perl script from within itself? for a method to cleanly do this.

[AgentM]

Why yes, you're right, but our friend, the late W. Richard Stevens goes farther and explains that the best method is as following:

#untested code conversion from C sources
exit if fork()!=0;
setsid();
$SIG{'HUP'}='IGNORE';
exit if fork()!=0;
chdir('/'); #prevents path-specific hax
umask(0); #clear file mode creation mask
openlog(...); #standard syslog call

With the second call to fork, we are guaranteed that the child is not a session leader and therefore cannot acquire a controlling terminal. We ignore SIGHUP since the session leader is soon to be terminated. Just an expansion on what you said. I certainly admire and trust the late Mr. Stevens very much!


AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

[c0d34w4y]

Try this...

    close STDIN; close STDOUT; close STDERR;

        if (open(DEVTTY, "/dev/tty")) {
            ioctl(DEVTTY,0x20007471,0);
            close DEVTTY;
        }

        open(STDIN,"</dev/null");
        open(STDOUT,">/dev/null");
        open(STDERR,">&STDOUT");

        # at this point there are two processes... for parent, fork wi
+ll return a 'true' number, 
        # for child it'll return 0. thus, parent will exit and child w
+ill remain to run.
        fork && exit; 
    # certain signals should be ignored
        $SIG{"HUP"} = $SIG{"ALRM"} = $SIG{"PIPE"} = $SIG{"INT"} = "IGN
+ORE"; 
    # set some priority for the process...
    # (so that it doesn't end up wasting your
    #  server resources)
        setpriority( "PRIO_PROCESS", 0, 10 );

[jeroenes]

If you run a script in a the background with exec, things go nasty after a while when you kill your terminal. You can prevent this (I tried it only under linux) by setting SIG{INT}='IGNORE'.

Actually, a better solution is the Proc::daemon module, or the Net::daemon module if you need to claim a socket.

Originally posted as a Categorized Answer.

[vroom]

testing

Originally posted as a Categorized Answer.

[jeroenes]

If you run a script in a the background with exec, things go nasty after a while when you kill your terminal. You can prevent this (I tried it only under linux) by setting SIG{INT}='IGNORE'.

Actually, a better solution is the Proc::daemon module, or the Net::daemon module if you need to claim a socket.

Originally posted as a Categorized Answer.

[reyjrar]

check out the question I asked yesterday.. lotsa good responses, I liked Fastolfe's suggestion myself.
sounds like what you're trying to do.

-brad..

Originally posted as a Categorized Answer.

[jeroenes]

If you run a script in a the background with exec, things go nasty after a while when you kill your terminal. You can prevent this (I tried it only under linux) by setting SIG{INT}='IGNORE'.

Actually, a better solution is the Proc::daemon module, or the Net::daemon module if you need to claim a socket.

[Fastolfe]

It's not the INT signal you need to worry about, but the HUP signal. This can also be averted by disassociating the new process from the old one (which also disassociates it from the controlling terminal, preventing things like the HUP broadcast from reaching it) by using POSIX's setsid function. I believe perlipc gives a good example of a "daemonize" function that does a good job of setting up a child process in such a way that it is completely disassociated from its parent.