RE: run perl as service

Thanks all guys, in particular for very quick answers :)

Chas, you can read my mind! That's exactly why I hesitated to use crontab.
But your solution is, in short, elegant! I'll try now to modify my script
with Jeff and cpan's Daemon suggestions. And anyhow, I'll do some testing
regarding performance and maintenance from what Andrew said.


Toddy Prawiraharjo

-----Original Message-----
From: Chas Owens [mailto:chas.owens@xxxxxxxxx]
Sent: Wednesday, August 08, 2007 10:36 PM
To: Andrew Curry
Cc: toddyp@xxxxxxxx; beginners@xxxxxxxx
Subject: Re: run perl as service

On 8/8/07, Andrew Curry <andrew.curry@xxxxxxxxxxxx> wrote:
To be honest in terms of database monitoring cron is usually the way to
The advantage Is that then you don't need to monitor the monitoring
As a DBA you need reliable data in terms of status etc... You could write
overcomplicated daemon which monitors its state but if cron is an option
much simpler and less can go wrong.

There are two downsides to cron: the finest resolution it can do is
one minute and it doesn't prevent overlapping runs. Now, you can
achieve sub minute timing by saying

* * * * *
* * * * * sleep .25;
* * * * * sleep .5;
* * * * * sleep .75;

But this still doesn't prevent multiple concurrent runs of So
now, we have to add code to to stop it from doing anything if
another copy is running (usually a lock file). But, if something goes
wrong the other copies might never run again. We are now back in the
same position as using a daemon, but without the benefits. Now, if
you have access to a scheduler other than can handle these sorts of
conditions (Control-M and CA Unicenter come to mind), then by all
means use them, but cron is not always a good choice. That said, if
you only need to run once per minute or less frequently and don't care
if the programs overlap, cron works just fine (unless you have access
to a better scheduler).