[DRBD-user] drbdadm down failed (-12) - blocked by drbd_submit

[Radoslaw Garbacz]

It turned out that the NFS daemon was blocking DRBD.
Thanks, the comment about the 'drbd' kernel processes was helpful.

BTW, the documentation (man pages) for DRBD 9.0 is still from 8.4 and some
options are no longer there.


On Thu, Oct 11, 2018 at 9:48 AM, Radoslaw Garbacz <
radoslaw.garbacz at xtremedatainc.com> wrote:

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



-- 
Best Regards,

Radoslaw Garbacz
XtremeData Incorporated
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20181017/fa7a8ac9/attachment.htm>