RE: run perl as service
- From: toddyp@xxxxxxxx (Toddy Prawiraharjo)
- Date: Wed, 8 Aug 2007 22:41:04 +1000
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.
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 togo.
The advantage Is that then you don't need to monitor the monitoringprogram.
As a DBA you need reliable data in terms of status etc... You could writean
overcomplicated daemon which monitors its state but if cron is an optionits
much simpler and less can go wrong.snip
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
* * * * * foo.pl
* * * * * sleep .25; foo.pl
* * * * * sleep .5; foo.pl
* * * * * sleep .75; foo.pl
But this still doesn't prevent multiple concurrent runs of foo.pl. So
now, we have to add code to foo.pl 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).