[ClusterLabs] dlm reason for leaving the cluster changes when stopping gfs2-utils service

[Momcilo Medic]

Dear all,

I have three hosts setup in my test environment.
They each have two connections to the SAN which has GFS2 on it.

Everything works like a charm, except when I reboot a host.
Once it tries to stop gfs2-utils service it will just hang.

I managed to pinpoint this to the umount command in the service's script.

However, I tried manually starting and stopping the service a lot of
times and had zero failures.
Further investigation shows difference between manual stopping of the
service and stopping of the service by the reboot.

First one lists reason to remove node as "leave" and latter's reason
is "nodedown".

I don't know why would we have different behaviour for the same
command (umount -a -t gfs2).

If the command wouldn't hang, I could suspect next service in order to
be the culprit, but this isn't the case. You can see the hosts output
in itafgfsxen02-reboot.

I am attaching logs from my machines and also corosync.conf.
dlm_controld is started with these options: "dlm_controld -D -f 0 -q 0
-s 0 -K -L"
If I missed any info, please don't hold back to request it :)

Any help will be highly appreciated.

Kind regards,
Momcilo "Momo" Medic.
(fedorauser)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itiafgfsxen01-corosync
Type: application/octet-stream
Size: 6476 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0024.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itiafgfsxen01-dlm
Type: application/octet-stream
Size: 2128 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0025.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itiafgfsxen02-corosync
Type: application/octet-stream
Size: 19516 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0026.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itiafgfsxen02-dlm
Type: application/octet-stream
Size: 2834 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0027.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itiafgfsxen02-reboot
Type: application/octet-stream
Size: 329 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0028.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itiafgfsxen03-corosync
Type: application/octet-stream
Size: 6346 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0029.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itiafgfsxen03-dlm
Type: application/octet-stream
Size: 2050 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0030.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corosync.conf
Type: application/octet-stream
Size: 1949 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160322/3e91a9b7/attachment-0031.obj>