[Pacemaker] Upstart resources

Andrew Beekhof andrew at beekhof.net
Wed Feb 29 02:49:37 EST 2012

On Wed, Feb 29, 2012 at 6:38 PM, Florian Haas <florian at hastexo.com> wrote:
> On Wed, Feb 29, 2012 at 8:21 AM, Andrew Beekhof <andrew at beekhof.net> wrote:
>> 2012/2/27 Ante Karamatić <ante.karamatic at canonical.com>:
>>> On 27.02.2012 12:27, Florian Haas wrote:
>>>> Alas, to the best of my knowledge the only way to change a specific
>>>> job's respawn policy is by modifying its job definition. Likewise,
>>>> that's the only way to enable or disable starting on system boot. So
>>>> there is a way to overrule the package maintainer's default -- hacking
>>>> the job definition.
>>> I've explained '(no)respawn' in the other mail. Manual starting/stopping
>>> is done by:
>>> echo 'manual' >> /etc/init/${service}.override
>>> That's all you need to forbid automatic starting or stopping the service.
>> Not really appropriate for a cluster daemon to be doing though IMHO
> Of course it wouldn't be the cluster daemon doing this but the admin,

I think the number of people that would think to do this after adding
an upstart service to the cluster approaches zero.

> but how is that so fundamentally worse
> compared to doing, say "chkconfig mysql off"?
> Having to keep a service from starting a daemon on boot is something
> that is fairly standard in Pacemaker environments these days.

But this isn't "start at boot", this is preventing respawn after
pacemaker starts it.

> Florian
> --
> Need help with High Availability?
> http://www.hastexo.com/now
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

More information about the Pacemaker mailing list