RE: run perl as service
- From: andrew.curry@xxxxxxxxxxxx (Andrew Curry)
- Date: Wed, 8 Aug 2007 13:40:52 +0100
Agreed but the problem with a daemon is you need to keep checking its
running if it doesn't run then you have no checks, for a database with
critical information this isnt viable, cron for all its problems is part of
the os makeup and can be trusted to run things at a certain time.
In this case the person is doing a simple show status, if this takes more
than a fraction of a minute then something is wrong. In general you wouldn't
be monitoring more than once a minute because of timeouts etc.. A lockfile
and check will surfice if it's a problem with running multiple instances
(should it take over a minute).
-----Original Message-----
From: Chas Owens [mailto:chas.owens@xxxxxxxxx]
Sent: 08 August 2007 13:36
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 couldsnip
write an overcomplicated daemon which monitors its state but if cron
is an option its 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
* * * * * 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).
This e-mail is from the PA Group. For more information, see
www.thepagroup.com.
This e-mail may contain confidential information. Only the addressee is
permitted to read, copy, distribute or otherwise use this email or any
attachments. If you have received it in error, please contact the sender
immediately. Any opinion expressed in this e-mail is personal to the sender
and may not reflect the opinion of the PA Group.
Any e-mail reply to this address may be subject to interception or
monitoring for operational reasons or for lawful business practices.
.
- Follow-Ups:
- Re: run perl as service
- From: Dr.Ruud
- Re: run perl as service
- Prev by Date: RE: run perl as service
- Next by Date: Re: How to read a very large file??
- Previous by thread: Re: run perl as service
- Next by thread: Re: run perl as service
- Index(es):
Relevant Pages
|
|
