[ClusterLabs] [corosync][pacemaker] runtime issues, while it builds OK

[Jan Pokorný]

On 30/06/16 11:26 +0200, Bogdan Dobrelya wrote:
> On 06/30/2016 11:16 AM, Bogdan Dobrelya wrote:
>> I'm building the libqb -> corosync -> pacemaker and commit each as a
>> separate docker container layer. Then I run the latter and spawn a
>> corosync with a simple config, then a pacemaker instance.
>> 
>> The issue is, that when I just run processes, the pacemaker complains
>> it has an ipc issues (strace dump):
>> 
>> connect(6, {sa_family=AF_LOCAL, sun_path=@"corosync.ipc"}, 110) = -1
>> ECONNREFUSED (Connection refused)
>> 
>> According to that I've found on that topic, it seems related to the
>> wrong libqb/corosync versions the pacemaker app was build for.
>> 
>> BUT, if I first *rebuild* libqb -> corosync -> pacemaker, then
>> *relaunch* corosync -> pacemaker, it works like a charm! I have no
>> explanation to that strange magic. Any ideas, why it is so?
>> 
>> Ofc, I can w/a that by a containers entry point like:
>> a corosync: build libqb -> corosync, then launch
>> a pacemaker: build libqb -> corosync -> pacemaker, then launch
>> 
>> But that'd be a really ugly band aiding and is a very long to start as well.
>> 
>> Note, the libqb/corosync builds are from a signed tarballs, the
>> pacemaker - from its github tag checked-out as I want to "play" with a
>> latest builds from trunc.
>> 
> 
> Hm, it seems the issue is with the artifacts make produces then I
> execute a libqb->corosync->pacemaker chain. If I build containers from
> mounted repos, throwing them out at the commit stage and leaving only
> the resulting artifacts, I have that strange behavior I've described
> above. But if I commit the build dirs into containers as well, it starts
> working w/o additional runtime rebuilds!
> 
> I thought the artifacts make produces are self contained. It seems they
> are not :(

Are you launching corosync + pacemaker directly from their build
directories (with some LD_LIBRARY_PATH magic so that the necessary
libraries are found) or do you "make install" for all three and go
from here?
Is there anything else that might be considered nonstandard?

The only idea at the moment would be to compare ./configure outputs
in a lucky and unlucky cases.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160701/ec279765/attachment-0003.sig>