<div dir="ltr">Thanks, will take a closer look at this.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 11, 2018 at 3:47 AM, Lars Ellenberg <span dir="ltr"><<a href="mailto:lars.ellenberg@linbit.com" target="_blank">lars.ellenberg@linbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Oct 02, 2018 at 12:56:38PM -0500, Radoslaw Garbacz wrote:<br>
> Hi,<br>
> <br>
> <br>
> I have a problem, which (from what I found) has been discussed, however not<br>
> in the particular case, which I experienced, so I would be grateful for any<br>
> suggestions of how to deal with it.<br>
> <br>
> <br>
> I.<br>
> 1. I get an error when demoting DRBD resource:<br>
> * drbdadm down data0<br>
> <br>
> data0: State change failed: (-12) Device is held open by someone<br>
> additional info from kernel:<br>
> failed to demote<br>
> Command 'drbdsetup-84 down data0' terminated with exit code 11<br>
> <br>
> 2. The device is not mounted and not used by any LVM, so based on some<br>
> online discussions I checked the blocking process and it is "drbd0_submit"<br>
> <br>
> * lsof | grep drbd0<br>
> drbd0_sub 16687 root cwd DIR 202,1 251 64 /<br>
<br>
</span>No, it is not.<br>
<br>
drbd*submitter (only 16 bytes of that name actually make it into the<br>
comm part of the task struct, which is what ps or lsof or the like can<br>
display) are kernel threads, and part of DRBD operations.<br>
They are certainly NOT "holding it open".<br>
They are a required part of its existence.<br>
<br>
"Holding it open" when you think you already unmounted it<br>
is typically either some forgotten device mapper thingy<br>
(semi-automatically created by kpartx e.g.),<br>
or some racy "udev triggered probe".<br>
<br>
In the latter case, if you retry after a couple seconds,<br>
demoting should work.<br>
<span class=""><br>
> Is there a good way to deal with this case, as whether some DRBD step is<br>
> missing, which leaves the process or killing the process is the right way?<br>
<br>
</span>Again, that "process" has nothing to do with drbd being "held open",<br>
but is a kernel thread that is part of the existence of that DRBD volume.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
: Lars Ellenberg<br>
: LINBIT | Keeping the Digital World Running<br>
: DRBD -- Heartbeat -- Corosync -- Pacemaker<br>
<br>
DRBD® and LINBIT® are registered trademarks of LINBIT<br>
__<br>
please don't Cc me, but send to list -- I'm subscribed<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<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>
</div></div></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>