[Pacemaker] pacemaker service start failed.

Andrew Beekhof andrew at beekhof.net
Tue Oct 30 00:51:38 EDT 2012

On Mon, Oct 29, 2012 at 7:10 PM, Yuusuke Iida
<iidayuus at intellilink.co.jp> wrote:
> Hi, Andrew
> (2012/10/26 9:31), Andrew Beekhof wrote:
>>> When I described the IP which I used in ring0 in /etc/hosts, I confirmed
>>> >that start of pacemaker succeeded.
>>> >
>> [moved first question to the end]
> I understood that name solution was necessary.
>>> >Was there any problem with a conventional method to use uname()?
>> The problem with uname() is that your peers don't know the value until
>> you send it to them.
>> Which creates a conceptual race condition - how do you send a message
>> to (or fence) a peer who's name you don't know yet?
> sorry, I did not understand it a little.
> What kind of situation is it?

Mostly during startup.
Since corosync only knows nodeids, that is all we know about our peers
until they send us a message (which contains their name).  So if we
need to send them a message before we hear from it, then we have no
way to how to address it.  Likewise, if one suffers a failure we have
no idea who to shoot.

>>> >Will setting to convert IP of such ring0 into the name be necessary by
>>> > all
>>> >means in future?
>> In a word "no":-)
>> There are a couple of options:
>> - you can specify the names to use in corosync.conf (nodelist)
>>    using a nodelist doesn't prevent you from using multicast
>> - you can setup /etc/hosts as you did above
>> - I have just now re-instated the uname() default for corosync 2.0
>> cluster types.  It didn't occur to me that people wouldn't set up
>> anything:-)
>>    The patch is:https://github.com/beekhof/pacemaker/commit/9a81945
>> can you give it a try?
> I tried this correction.
> The correction seems to run without a problem.

I will probably amend that patch to drop everything after the first '.'
Does that sound like a good idea to you?

More information about the Pacemaker mailing list