On 8/8/07, Andrew Curry <[EMAIL PROTECTED]> wrote: > To be honest in terms of database monitoring cron is usually the way to go. > The advantage Is that then you don't need to monitor the monitoring program. > As a DBA you need reliable data in terms of status etc... You could write an > overcomplicated daemon which monitors its state but if cron is an option its > 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). -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
