[Pacemaker] use_logd or use_mgmtd kills corosync

[Steven Dake]

On 06/08/2010 11:20 PM, Andrew Beekhof wrote:
> On Wed, Jun 9, 2010 at 7:27 AM, Devin Reade<gdr at gno.org>  wrote:
>> I was following the instructions for a new installation of corosync
>> and was wanting to make use of hb_gui so, following an installation
>> via yum per the docs, built Pacemaker-Python-GUI-pacemaker-mgmt-2.0.0
>> from source.
>>
>> Starting corosync works normally without mgmtd in the picture, but as
>> soon as *either* of the two lines are added to /etc/corosync/service.d/pcmk,
>> corosync fails to start with no diagnostics in the logfile or syslog:
>>     use_logd: 1
>>     use_mgmtd: 1
>>
>> I ran 'strace corosync -f' and got rather uninformative information, the
>> tail end of it shown here:
>>
>> statfs("/etc/corosync/service.d", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096,
>> f_blocks=507860, f_bfree=388733, f_bavail=362519, f_files=524288,
>> f_ffree=517073, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
>> getdents(3, /* 3 entries */, 32768)     = 72
>> stat("/etc/corosync/service.d/pcmk", {st_mode=S_IFREG|0644, st_size=101,
>> ...}) = 0
>> open("/etc/corosync/service.d/pcmk", O_RDONLY) = 4
>> fstat(4, {st_mode=S_IFREG|0644, st_size=101, ...}) = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0x2acb16dd5000
>> read(4, "service {\n \t# Load the Pacemaker"..., 4096) = 101
>> close(4)                                = 0
>> munmap(0x2acb16dd5000, 4096)            = 0
>> close(3)                                = 0
>> exit_group(8)                           = ?
>>
>>
>> Any thoughts?
>
> Not really.
> Do any other children start up?
> Where is the mgmtd binary installed to?
>
>> # uname -srv
>> Linux 2.6.18-194.3.1.el5 #1 SMP Thu May 13 13:08:30 EDT 2010
>>
>> # rpm -q -a | grep openais | sort
>> openais-1.1.0-2.el5.i386
>> openais-1.1.0-2.el5.x86_64
>> openaislib-1.1.0-2.el5.i386
>> openaislib-1.1.0-2.el5.x86_64
>> openaislib-devel-1.1.0-2.el5.i386
>> openaislib-devel-1.1.0-2.el5.x86_64
>>
>>
>> ################### /etc/corosync/corosync.conf ################
>> compatibility: none
>>
>> totem {
>>         version: 2
>>         secauth: off
>>         threads: 0
>>         interface {
>>                 ringnumber: 0
>>                 # but with a real netaddr, obviously
>>                 bindnetaddr: A.B.C.D
>>                 mcastaddr: 226.94.1.1
>>                 mcastport: 5405
>>         }
>> }
>>
>> logging {
>>         fileline: off
>>         to_stderr: no
>>         to_file: yes
>>         to_syslog: yes
>>         logfile: /var/log/corosync.log
>>         # debug: off
>>         timestamp: on
>>         logger_subsys {
>>                 subsys: AMF
>>                 debug: off
>>         }
>> }
>>
>> amf {
>>         mode: disabled
>> }
>>
>> aisexec {
>>         user: root
>>         group: root
>> }
>>
>> #################### /etc/corosync/service.d/pcmk #############
>> service {
>>         # Load the Pacemaker Cluster Resource Manager
>>         name: pacemaker
>>         ver:  0
>>         use_logd: 1
>> }
>>
>>
>> _______________________________________________
>> 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>>
>
> _______________________________________________
> 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker

This is likely the sem_wait issue related to some CentOS deployments. 
An update for corosync is pending release.  Hopefully new source 
tarballs will be available Wednesday.

Regards
-steve