From: Fabio M. Di Nitto <fdinitto@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] when do I need to start cpglockd
Date: Tue, 19 Jun 2012 10:33:30 +0200 [thread overview]
Message-ID: <4FE0395A.9090308@redhat.com> (raw)
In-Reply-To: <24E144B8C0207547AD09C467A8259F754B95DDE6@lisa.maurer-it.com>
On 6/19/2012 10:12 AM, Dietmar Maurer wrote:
>> At boot rgmanager starts fine, without cpglockd running.
>> I think the problem here is the interpretation of the LSB specifications
>> between different distributions. I am not going to argue which one is right or
>> wrong but the key issue is here:
>>
>> "An init.d shell script may declare using the "Required-Start: " header that it
>> shall not be run until certain boot facilities are provided.
>> This information is used by the installation tool or the boot-time boot-script
>> execution facility to assure that init scripts are run in the correct order."
>>
>> In the fedora world that means that if cpglockd is enabled (via chkconfig), the
>> Required-Start: make sure that cpglockd is started before rgmanager, always.
>>
>> It is possible that other distributions might interpret that as:
>> "cpglockd must be started even if disabled" when rgmanager
>> Required-Start: cpglockd and rgmanager is enabled.
>>
>> So based on the platform I use for testing/development, the daemon does
>> not start unless it is necessary :)
>
> OK, I was not aware of that.
>
> Many thanks for that detailed reply!
So let?s instead try to figure out the correct fix.
Let?s put one minute aside the possibility that some distributions might
use the second interpretation of LSB header and focus only on the
ordering instead.
Dropping Required-Start: might look like an easy fix in the Debian
world, but that could cripple the startup order as cpglockd could
theoretically land after rgmanager (i don?t think it?s possible, but
let?s not take a chance).
I think the correct fix should be:
move the conditional start start_cpglockd function/check from
rgmanager.init to cpglockd.init.
move the "cpglockd is up and running" test from rgmanager.init to
cpglockd.init (that?s a bug as-is now).
cpglockd.init should return 0 (success) if it does not need to run and
would allow rgmanager to start given Debian current interpretation of
LSB header.
rgmanager.init can simply fire cpglockd.init without any check, as those
would be done properly by cpglockd.init.
I think this should solve the issue for Debian and keep current behavior
in Fedora.
Fabio
next prev parent reply other threads:[~2012-06-19 8:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 15:26 [Cluster-devel] when do I need to start cpglockd Dietmar Maurer
2012-06-14 12:21 ` Ryan McCabe
2012-06-14 15:41 ` Dietmar Maurer
2012-06-14 16:06 ` Ryan McCabe
2012-06-19 3:44 ` Fabio M. Di Nitto
2012-06-19 4:23 ` Dietmar Maurer
2012-06-19 6:20 ` Fabio M. Di Nitto
2012-06-19 6:54 ` Dietmar Maurer
2012-06-19 7:03 ` Fabio M. Di Nitto
2012-06-19 7:24 ` Dietmar Maurer
2012-06-19 8:04 ` Fabio M. Di Nitto
2012-06-19 8:12 ` Dietmar Maurer
2012-06-19 8:33 ` Fabio M. Di Nitto [this message]
2012-06-19 8:36 ` Dietmar Maurer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE0395A.9090308@redhat.com \
--to=fdinitto@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).