Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^2: Auto-restarting script if it dies

by sgifford (Prior)
on Mar 09, 2007 at 16:18 UTC ( #604001=note: print w/replies, xml ) Need Help??

in reply to Re: Auto-restarting script if it dies
in thread Auto-restarting script if it dies

On Unix, daemontools provides a fairly straightforward way to do exactly what merlyn describes without writing any code. It goes a step further, and has one additional process monitoring all of the monitoring process, with that process restarted by init. That's pretty foolproof, and it's straightforward to set up many monitored services.

Replies are listed 'Best First'.
Re^3: Auto-restarting script if it dies
by mojodaddy (Pilgrim) on Mar 09, 2007 at 21:18 UTC
    As a matter of fact, I spent a few hours grappling with daemontools, and it's a perfect example of the freakishly opaque "explanations" I described in my original post. Here's its FAQ entry for the question "How do I create a service directory?":

    Answer: The only required component of your service directory is an executable file, ./run, that runs your daemon in the foreground, exiting when your daemon exits.

    Huh? Does that mean I'm supposed to create ./run? And if so, what is it? And how, exactly, do I create it? The FAQ says:

    Typically ./run is a shell script. For example:

    echo starting
    exec clockspeed

    "Typically?" So is my situation typical? How can I tell? And if ./run is a shell script in a typical case, what is it in other cases?

    So let's assume that I am supposed to write a shell script (which in my case would execute my perl script?) and save it as ./run in my service directory. But if so, why not just say so? Plus, would it kill them to explain how? It's like if I said, "How is a moon-rock different from a regular rock?" and they said "OK, first go to the moon and get some rocks, and I'll tell you the rest when you get back..."

    Of course the reality is that if the daemontools FAQ had been anything less than completely baffling, I wouldn't have written my solution, in which case I would never had received a personal response from merlyn! So it's all good. : )

      'typically' doesn't refer to the situation but to the script, which could be a c-program, a shell script or a perl-script. It's left up to you what you want in it. You could put the deamon itself there or just a script that starts the daemon, or a script that starts a script that starts the daemon ;-)

      In most cases you've got the daemon executable somewhere else, so typically aka usually you put a script there.

      The key to understanding these tools is to read the documentation for the programs to see exactly what they do, then extrapolate from there. See, for example, the supervise manual. The reason the instructions are a bit vague is because, as with most of Unix, the software consists of a small tool which can be combined with other small tools in any number of different ways; how you will combine them will depend on exactly what you hope to accomplish.

      In this case, the key thing that supervise does is execute whatever's in the file named run, then starts it back up again if it exits. run can be a shell script, a perl script, a binary program, a symlink, or anything else that Unix knows how to execute. In your case, you probably want either a shell script to exec your program, or else a symlink to your actual program as your run script.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://604001]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2021-01-24 01:10 GMT
Find Nodes?
    Voting Booth?