Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

fork process + SIG handlers

by cidaris (Friar)
on Dec 03, 2004 at 22:34 UTC ( #412304=perlquestion: print w/replies, xml ) Need Help??

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

I am using the following method to fork off and dissociate from the terminal for a script I want to daemonize. Now, I'm told I could just do some while(1) { sleep; } trickery, but I would think there'd be a way to do it without resorting to that. The script should last forever as is, as it uses File::Tail to watch a log. Permissions are OK, as if I remove the sighandler stuff, I can watch it output exactly what I'm looking for.
defined(my $pid = fork) or die "Can't fork: $!\n"; exit if $pid; setsid or die "Can't start a new session: $!\n"; + + $SIG{'HUP'} = $SIG{'INT'} = $SIG{'KILL'} = $SIG{'TERM'} = &sig_handler +; my $connection_log = "/var/log/qmail/qmail-smtpd/current"; if(-e $connection_log){ my $file = File::Tail->new($connection_log); my $line; while (defined($line = $file->read)) { print "Line contents: $line\n"; } } sub sig_handler { my $sig = shift; print "Received SIG $sig\n"; quit(0); }
Now, I would think that it would run forever (as long as the file was moving) and occasionally print the signals it received, except it dies immediately because the fork kills it. Does someone have a tutorial or a link they could present to do what I think I'm trying to do? Alternatively, education as to WIDIAW (why i'm doing it all wrong) would also be appreciated :) Does the file being rotated out kill File::Tail? The documentation suggests that it handles that situation. Update: It's fairly obvious why it's quitting to me (quit) Forget that part, the question still stands, am I daemonizing the wrong way?

Replies are listed 'Best First'.
Re: fork process + SIG handlers
by tachyon (Chancellor) on Dec 04, 2004 at 00:00 UTC

    Here is a daemon that does the right things:

    #!/usr/bin/perl -w $|++; use strict; use Fcntl; use POSIX qw(setsid); my ($PROGRAM) = $0 =~ m!([^\\/:]+)$!; my $LOCKFILE = "/var/lock/$PROGRAM"; my $LOG = "/var/log/$PROGRAM.error.log"; # use a lockfile to prevent spawning duplicate processes unless ( sysopen(my $fh, $LOCKFILE, O_CREAT | O_EXCL | O_RDWR, 0600) ) + { # the lockfile already exists print "Lockfile $LOCKFILE aready exists.\nChecking for running $PR +OGRAM process..."; my @ps = grep{ m/\Q$PROGRAM\E/ } `ps -C $PROGRAM`; # we expect 1 copy (us) running # print "@ps\n"; die "\nThere is already a copy of $PROGRAM running!\n" if @ps > 1; print "None!\n"; } # now demonize it defined(my $pid = fork) or die "Can't fork: $!"; exit 0 if $pid; chdir '/' or die "Can't chdir to /: $!"; umask 0; setsid() or die "Can't start a new session: $!"; $SIG{INT} = $SIG{TERM} = sub { unlink $LOCKFILE or warn "Could not unlink $LOCKFILE for $PROGRAM\ +n"; exit; }; $SIG{HUP} = sub { warn "Caught HUP " . time() . "\n"; # do reset stuff if required }; print "Started $0 daemon OK\n\n"; open STDIN, '/dev/null' or die "Can't read /dev/null: $!"; open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!"; #open STDERR, '>/dev/null' or die "Can't write to /dev/null: $!"; open STDERR, ">>$LOG" or die "Can't write to $LOG: $!"; # this is the main loop that runs forever, once every 30 seconds while (1) { eval{ ... }; # use eval to exec any code so if it chokes the dae +mon survives warn "$@\n" if $@; sleep 30; }



      umask 0;
      Wouldn't it be safer to set umask 002 at least? I don't think it's a good idea to create world-writable files.

        You are right. Perhaps I should have added an YMMV ;-)

Re: fork process + SIG handlers
by rev_1318 (Chaplain) on Dec 03, 2004 at 23:21 UTC
    When you want to create a daemon, you should keep in mind a few things:
    1. redirect STDOUT, STDERR to a file or /dev/null
    2. redirect STDIN to /dev/null
    3. create a 'save' environment:
      change working directory to something save
      set your $ENV{PATH} to a save value
      set the umask to a save value


Re: fork process + SIG handlers
by BUU (Prior) on Dec 04, 2004 at 05:01 UTC
    SIG{'HUP'} = $SIG{'INT'} = $SIG{'KILL'} = $SIG{'TERM'} = &sig_handler; This is wrong, it calls the subroutine sig_handler and assigns the result of that function call to the variables. You want either $SIG{FOO}='sig_handler'; or $SIG{FOO} = \&sig_handler;
Re: fork process + SIG handlers
by Zaxo (Archbishop) on Dec 04, 2004 at 04:22 UTC

    Note that $SIG{KILL} is not really assigned. That is intentional by the OS. The reason is that root needs a way to poleaxe a runaway process.

    After Compline,

      What? Assigned? Sure it is. $SIG{KILL} is a perfectly valid signal handler. The only difference between it and sigint is that you can't actually catch a sigkill, you can just respond to it. Or am I thinking of sigterm..

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://412304]
Approved by Arunbear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (6)
As of 2023-03-28 12:05 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (67 votes). Check out past polls.