On Fri, Mar 28, 2008 at 6:02 PM, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > > On Mar 28, 2008, at 3:14 PM, Dejan Muhamedagic wrote: > > > Hi, > > > > On Fri, Mar 28, 2008 at 12:47:14PM +0000, David Thompson wrote: > >> Hello: > >> > >> I have been asked to schedule a service managed by heartbeat to > >> restart every 24 hours (this is common practice in my company). > > > > Interesting practice. > > > >> If I were to add a RESTART OPERATION to the CIB.XML for that > >> service with say an interval of 86400s, would that do the > >> trick? :-) > > > > No. There's no restart operation. The only operation which can > > recur is monitor anyway. > > Actually thats wrong. > Recurring actions can have whatever name they like. > True the standard is "monitor", but there is nothing to stop David > from doing exactly what he's proposing - I believe it will work. > > And because resource operations are serialized, there is no chance > that another recurring monitor will run at just the wrong time and > think the resource is failed.
How about simply stopping the resource "outside" of heartbeat e.g. via cron and let the monitor action detect the "failure" and initiate a restart of the resource? .... If resource_failure_stickiness is not used to failover services.... Regards, Andreas > > > > > You would have to use cron. Set the > > target_role to "stopped", wait until the DC becomes idle (see the > > attachment for an example) which would mean that the service got > > really stopped, then remove the target_role attribute or set it > > to "started". > > > > Thanks, > > > > Dejan > > > >> Thanks so much for your help. > >> > >> Cheers, > >> > >> David > >> > >> ________________________________________________________________________ > >> > >> CONFIDENTIALITY - This email and any files transmitted with it, are > >> confidential, may be legally privileged and are intended solely for > >> the use of the individual or entity to whom they are addressed. If > >> this has come to you in error, you must not copy, distribute, > >> disclose or use any of the information it contains. Please notify > >> the sender immediately and delete them from your system. > >> > >> SECURITY - Please be aware that communication by email, by its very > >> nature, is not 100% secure and by communicating with Perform Group > >> by email you consent to us monitoring and reading any such > >> correspondence. > >> > >> VIRUSES - Although this email message has been scanned for the > >> presence of computer viruses, the sender accepts no liability for > >> any damage sustained as a result of a computer virus and it is the > >> recipient?s responsibility to ensure that email is virus free. > >> > >> AUTHORITY - Any views or opinions expressed in this email are > >> solely those of the sender and do not necessarily represent those > >> of Perform Group. > >> > >> COPYRIGHT - Copyright of this email and any attachments belongs to > >> Perform Group, Companies House Registration number 6324278. > >> _______________________________________________ > >> Linux-HA mailing list > >> [email protected] > >> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >> See also: http://linux-ha.org/ReportingProblems > > <dcidle.sh>_______________________________________________ > > > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
