Perl Daemon Calling a script

[perlology]

I wish I could use Proc::Daemon, but I need to resort the creating my own daemon code. This daemon calls a script that performs a few input and output operations periodically. One of the input and outputs commands in the script is 'sed', using 'echo' to append to a file, using 'printf' to log to a logfile.

The 'sed' commands are not working from the script. One of the errors messages is bad file descriptors. The 'echo' commands are echoing too may lines.

Is best to not call a script and just rewrite the shell script using Perl?

Or am I fundamentally missing something in my Perl code in calling the shell script?

#!/usr/bin/perl -Tw
#
#

use strict;
use POSIX qw(setsid);

use constant VERSION => 1.10;

$ENV{'PATH'} = '/bin';
delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};

my $PID_FILENAME = "/var/run/one-user-only.pid";
my $ONE_USER_ONLY = "/usr/local/bin/one-user-only.sh";

#
# If this file does exist, then just die accordingly
#
die("$PID_FILENAME exists!!") if ( -f $PID_FILENAME );

#
# If this file does not exist, then just die accordingly
#
die("Cannot find $ONE_USER_ONLY") if ( ! -f $ONE_USER_ONLY );

sub daemonize {

    chdir "/";

    # Close all default file descriptors
    open (STDIN, "</dev/null");
    open (STDOUT, ">/dev/null");
    open (STDERR, ">&STDOUT");
    
    my $pid = fork ();

    # Write the PID to /var/run
    open (FD, ">$PID_FILENAME") or die("Cannot write PID: $!");
    print FD "$$\n";
    close(FD);

    # Detach from the terminal so interrupts cannot occur
    if ($pid < 0) {
        die "fork: $!";
    } elsif ($pid) {
        exit 0;
    }

    # Make session leader
    setsid or die "setsid: $!";
    umask 0;

    foreach (0 .. (POSIX::sysconf (&POSIX::_SC_OPEN_MAX) || 1024)) {
        POSIX::close $_
    }
}

my $continue = 1;
$SIG{TERM} = sub { unlink $PID_FILENAME; $continue = 0; };

&daemonize;

while ($continue) {
    sleep 2;
    system($ONE_USER_ONLY);
}

[roboticus]

perlology:

A few notes in no particular order:

• I'd suggest redirecting your output to a scratch file while debugging, just in case the daemonized and/or shell script emits some errors that might help you along. You can use /dev/null after you have it properly demonified.
• Should you rewrite the shell script in perl? That depends: If the script is tiny and easy to convert, then I'd do so. If it's large it may not be worth the hassle. If you like, you might write a couple of chunks of it in perl, and call that from the shell script, and as you maintain it, you can suck more of the shell script into perl as makes sense. For example, I can never remember sed well enough to use it, so I just use perl for all my sed jobs.
• It looks like you may be removing $PID_FILENAME too soon. It appears that when you do the "detach terminal" bit, after the fork, it'll get dropped. You might want to add your signal handler after you've achieved complete deemonification.

Note: Yes, the entire reason for this post was so I could write a couple goofy variations on the word 'daemon'. I had a couple other variations, but forgot 'em before I found a place to put 'em.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[perlology]

Thank you for the pragmatic approach. I am moving forth with those suggestions now.

[Anonymous Monk]

I wish I could use Proc::Daemon, but I need to resort the creating my own daemon code.

:) obligatory Yes, even you can use CPAN Top 11 (GOOD) reasons not to use someone else's Modules, Top Seven (Bad) Reasons Not To Use Modules

[perlology]

Understood .. The context in which I work does not allow me to easily to add modules to the system. My technical questions still stand. Are my problems with the script because of the daemon code? The script works well manually from the commandline .....

[roboticus]

If it works well from the command line, but is giving you trouble when you execute it in some other way, it's frequently an environmental issue. A couple things to check:

• Does the account you're running it from have permissions to access/execute everything?
• Starting an account without using login (such as when running from cron) frequently has a different PATH and other environment variables set up. I typically print a copy of all the %ENV values when debugging problems like this.

...roboticus

When your only tool is a hammer, all problems look like your thumb.