<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thank you for your answer.</div><div><br></div><div>The reported issue happens with drbd84 on CentOS7, details:</div><div>[root@ip-10-102-233-230 ~]# uname -r<br>3.10.0-862.14.4.el7.x86_64</div><div><br></div><div>DRBDADM_BUILDTAG=GIT-hash:\ c0fb2d367b8be5e9f53919f88a8c344dc8c61fe9\ build\ by\ mockbuild@Build64R6\,\ 2016-12-13\ 17:38:13<br>DRBDADM_API_VERSION=1<br>DRBD_KERNEL_VERSION_CODE=0x080409<br>DRBDADM_VERSION_CODE=0x080908<br>DRBDADM_VERSION=8.9.8</div><div><br></div><div>Once installing drbd90 I encounter problems with parsing my resource configuration files (even though the documentation has not changed: man drbd.conf), besides the obvious removed support for 'max-bio-bvecs' and 'unplug-watermark' the tool does not dump 'startup' section when using: drbdadm dump "resource", however when I introduce intentional error in section 'startup' it does complain about the syntax:</div><div><br></div><div>1. Intentional error:<br></div><div> startup {<br> testing;<br> become-primary-on ip-10-102-233-230.ec2.internal;<br> }</div><div><br></div><div>results in reported syntax:</div><div>[root@ip-10-102-233-230 ~]# drbdadm dump data0 <br>drbd.d/data0.res:128: Parse error: '<an option keyword> | become-primary-on | stacked-timeouts' expected,<br> but got 'testing'<br></div><div><br></div><div>2. Proper (?) 'startup' section:</div><div> startup {<br> become-primary-on ip-10-102-233-230.ec2.internal;<br> }</div><div><br></div><div>results in no 'startup' section listed on 'dump':</div><div>[root@ip-10-102-233-230 ~]# drbdadm dump data0 | grep startup<br>[root@ip-10-102-233-230 ~]# <br></div><div><br></div><div>Is this intentional, i.e. not to dump 'startup' section?</div><div><br></div><div>Details:</div><div>[root@ip-10-102-233-230 xdcluster]# drbdadm --version<br>DRBDADM_BUILDTAG=GIT-hash:\ fed9a1df82015e52c14c912fa4b93336e2ab4fcc\ build\ by\ mockbuild@\,\ 2018-04-20\ 19:30:46<br>DRBDADM_API_VERSION=2<br>DRBD_KERNEL_VERSION_CODE=0x09000e<br>DRBD_KERNEL_VERSION=9.0.14<br>DRBDADM_VERSION_CODE=0x090301<br>DRBDADM_VERSION=9.3.1<br><br></div><div><br></div><div>Thanks in advance,<br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 3, 2018 at 1:44 AM, Julien Escario <span dir="ltr"><<a href="mailto:julien.escario@altinea.fr" target="_blank">julien.escario@altinea.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le 02/10/2018 à 19:56, Radoslaw Garbacz a écrit :<br>
> Hi,<br>
> <br>
> <br>
> I have a problem, which (from what I found) has been discussed, however not in<br>
> the particular case, which I experienced, so I would be grateful for any<br>
> suggestions of how to deal with it.<br>
<br>
</span>Your problem sounds pretty similar to a recent experience we had BUT with DRBD9<br>
(and drbdmanage).<br>
<br>
You can try to force disconnect by firwalling ports 7789/7790 with iptables on<br>
nodes and try to force socket disconnect with <a href="http://killcx.sourceforge.net/" rel="noreferrer" target="_blank">http://killcx.sourceforge.net/</a><wbr>.<br>
<br>
I didn't manage to get rid of this situation without rebooting a node.<br>
<br>
I was told to upgrade the drbd kernel module.<br>
<br>
Good luck !<br>
Julien<br>
______________________________<wbr>_________________<br>
drbd-user mailing list<br>
<a href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a><br>
<a href="http://lists.linbit.com/mailman/listinfo/drbd-user" rel="noreferrer" target="_blank">http://lists.linbit.com/<wbr>mailman/listinfo/drbd-user</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Best Regards,<br><br>Radoslaw Garbacz<br></div>XtremeData Incorporated<br></div></div></div></div>
</div>