Perl daemon (demon) runs from command line but not in startup script 
Author Message
 Perl daemon (demon) runs from command line but not in startup script

I have written a Perl daemon that works fine when I run it from the
command line. However, if I try to run it from within a startup script
in /etc/rc.d/init.d I run into problems. The script spawns child
processes that keep dieing whenever they attempt to run a backtick
command.

To create the startup script, I just copied an existing one and
changed a few lines. The changed portion looks like this:

prog="mydaemon"
start() {
        # Check if mydaemon is already running
        if [ ! -f /var/lock/subsys/mydaemon ]; then
            echo -n $"Starting $prog: "
            daemon "/usr/local/mydaemon/mydaemon -d"
            RETVAL=$?
            [ $RETVAL -eq 0 ] && touch /var/lock/subsys/mydaemon
            echo
        fi
        return $RETVAL

Quote:
}

What does the daemon command do that might be causing such a problem?


Wed, 12 Jan 2005 06:11:17 GMT  
 Perl daemon (demon) runs from command line but not in startup script

Quote:
>I have written a Perl daemon that works fine when I run it from the
>command line. However, if I try to run it from within a startup script
>in /etc/rc.d/init.d I run into problems. The script spawns child
>processes that keep dieing whenever they attempt to run a backtick
>command.

>To create the startup script, I just copied an existing one and
>changed a few lines. The changed portion looks like this:

>prog="mydaemon"
>start() {
>        # Check if mydaemon is already running
>        if [ ! -f /var/lock/subsys/mydaemon ]; then

This is a bad idea. Far better is to parse the output of ps to see what is
running.

Quote:
>            echo -n $"Starting $prog: "
>            daemon "/usr/local/mydaemon/mydaemon -d"
>            RETVAL=$?
>            [ $RETVAL -eq 0 ] && touch /var/lock/subsys/mydaemon
>            echo
>        fi
>        return $RETVAL
>}

>What does the daemon command do that might be causing such a problem?

Maybe it is starting in the wrong directory or running as a user that does
not have read/write permission. Try capturing stderr & stdout to a file.

gtoomey



Wed, 12 Jan 2005 06:36:08 GMT  
 Perl daemon (demon) runs from command line but not in startup script

Quote:


>>I have written a Perl daemon that works fine when I run it from the
>>command line. However, if I try to run it from within a startup script
>>in /etc/rc.d/init.d I run into problems. The script spawns child
>>processes that keep dieing whenever they attempt to run a backtick
>>command.

>>To create the startup script, I just copied an existing one and
>>changed a few lines. The changed portion looks like this:

>>prog="mydaemon"
>>start() {
>>        # Check if mydaemon is already running
>>        if [ ! -f /var/lock/subsys/mydaemon ]; then

>This is a bad idea. Far better is to parse the output of ps to see what is
>running.

Actually the lock files are a rather good idea -- and just checking the
process table is the bad one. Consider attempting to run several different
instances of a single server program on a single machine (f.ex. Apache;
there are valid reasons to do this). But then, this discussion goes into
domain of comp.unix.admin and has no place here.

Quote:
>>What does the daemon command do that might be causing such a problem?

>Maybe it is starting in the wrong directory or running as a user that does
>not have read/write permission. Try capturing stderr & stdout to a file.

Also, $PATH might be different than in shell sessions -- and depending
on where in the startup sequence the script is placed, the filesystem
containing the external commands to run might not be mounted yet.
--
Wolf  a.k.a.  Juha Laiho     Espoo, Finland

         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)


Wed, 12 Jan 2005 09:32:01 GMT  
 Perl daemon (demon) runs from command line but not in startup script

Quote:




>>>I have written a Perl daemon that works fine when I run it from the
>>>command line. However, if I try to run it from within a startup script
>>>in /etc/rc.d/init.d I run into problems. The script spawns child
>>>processes that keep dieing whenever they attempt to run a backtick
>>>command.

>>>To create the startup script, I just copied an existing one and
>>>changed a few lines. The changed portion looks like this:

>>>prog="mydaemon"
>>>start() {
>>>        # Check if mydaemon is already running
>>>        if [ ! -f /var/lock/subsys/mydaemon ]; then

>>This is a bad idea. Far better is to parse the output of ps to see what is
>>running.

>Actually the lock files are a rather good idea -- and just checking the
>process table is the bad one. Consider attempting to run several different
>instances of a single server program on a single machine (f.ex. Apache;
>there are valid reasons to do this). But then, this discussion goes into
>domain of comp.unix.admin and has no place here.

It depends. If the process falls over and never removes the lock, subsequent
invocations will not work.

gtoomey



Wed, 12 Jan 2005 10:03:03 GMT  
 Perl daemon (demon) runs from command line but not in startup script

Quote:




> >>>prog="mydaemon"
> >>>start() {
> >>>        # Check if mydaemon is already running
> >>>        if [ ! -f /var/lock/subsys/mydaemon ]; then

> >>This is a bad idea. Far better is to parse the output of ps to see what is
> >>running.

> >Actually the lock files are a rather good idea -- and just checking the
> >process table is the bad one. Consider attempting to run several different
> >instances of a single server program on a single machine (f.ex. Apache;
> >there are valid reasons to do this). But then, this discussion goes into
> >domain of comp.unix.admin and has no place here.

> It depends. If the process falls over and never removes the lock, subsequent
> invocations will not work.

I am interested in the outcome of this as I have recently deployed a daemon and
opted for a lock file, well, a pid file.

The name of the pid file is made unique by a command line parameter, thus a
user cannot start multiple instances of my daemon given the same parameter as
the pid file will already exist.

I can exit the daemon nicely and delete the pid file when I catch a specified
signal.

The pid file is written to /tmp so if the server crashes/reboots then the pid
file is cleared.

The daemon won't (well, shouldn't) die after instantiation as it is littered
with eval{};s.

The only thing I can't handle or cope with is if the daemon is killed by signal
9 or set to sleep.  In either of these two instances it is up to the user to
`ps` and check for pid files.

I am interested if other people agree that this is a good way of dealing with
the lock file issue?

Andy



Wed, 12 Jan 2005 14:39:49 GMT  
 Perl daemon (demon) runs from command line but not in startup script

Quote:





>> >>>prog="mydaemon"
>> >>>start() {
>> >>>        # Check if mydaemon is already running
>> >>>        if [ ! -f /var/lock/subsys/mydaemon ]; then

>> >>This is a bad idea. Far better is to parse the output of ps to see what
is
>> >>running.

>> >Actually the lock files are a rather good idea -- and just checking the
>> >process table is the bad one. Consider attempting to run several
different
>> >instances of a single server program on a single machine (f.ex. Apache;
>> >there are valid reasons to do this). But then, this discussion goes into
>> >domain of comp.unix.admin and has no place here.

>> It depends. If the process falls over and never removes the lock,
subsequent
>> invocations will not work.

>I am interested in the outcome of this as I have recently deployed a daemon
and
>opted for a lock file, well, a pid file.

>The name of the pid file is made unique by a command line parameter, thus a
>user cannot start multiple instances of my daemon given the same parameter
as
>the pid file will already exist.

>I can exit the daemon nicely and delete the pid file when I catch a
specified
>signal.

>The pid file is written to /tmp so if the server crashes/reboots then the
pid
>file is cleared.

>The daemon won't (well, shouldn't) die after instantiation as it is
littered
>with eval{};s.

>The only thing I can't handle or cope with is if the daemon is killed by
signal
>9 or set to sleep.  In either of these two instances it is up to the user
to
>`ps` and check for pid files.

>I am interested if other people agree that this is a good way of dealing
with
>the lock file issue?

>Andy

It's not that hard. I use the following fragment to kill runaway processes:

for (split '\n', qx(ps -u $> -o pid,tname,etime,cmd --no-headers)) { # $> is
the current user id
                ($pid, $tname, $etime,$cmd) = unpack "a5 x a11 x a8 x
a200",$_;
                $etime =~ /((\d*):)?(\d*):(\d*)$/;
                $ehour  = $2; #elapsed hours
                $emin   = $3;  # elapsed mins
                $background=/\?/;  #backgoround or foreground
                if ($ehour>4 ||
((!/sshd/)&&$background&&($ehour>=1||$emin>10))) {
                        kill 9,$pid;
                }

Quote:
}

gtoomey


Wed, 12 Jan 2005 15:13:46 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. How to distinguish between cron-startup and command-line startup

2. Script error:"did not produce a valid header", but runs ok from command line

3. GD.pm problem: script runs fine on command line but not across webserver

4. perl program works on command line, but not when run through www server

5. running perl at command line with arguments: script.cgi?text=text

6. Run perl script on web server from command line

7. Running a Perl/CGI form script from the command line

8. running perl at command line with arguments: script.cgi?text=text

9. system commands running but not .exe from perl script

10. Running CGI perl script from command line

11. Looking for command line to run PERL scripts on Mac

12. Piping problem running perl script from NT command line

 

 
Powered by phpBB® Forum Software