Udev rule causes automatic incorrect unmount of dm device

[Matt Schulte]

1) The release of Ubuntu you are using, via 'lsb_release -rd'

Description: Ubuntu Xenial Xerus (development b ranch)
Release: 16.04

2) The version of the package you are using, via 'apt-cache policy pkgname'

systemd:
  Installed: 229-3ubuntu1
  Candidate: 229-3ubuntu1

3) What you expected to happen

I am testing our E-Series Netapp storage array and the ability of the server to failover IO to the secondary path. I pull a cable and allow DM-MP to fail the path and route IO down the other path. I then replug the cable and repeat for the other path.

I expect that the failover to occur and for the mount points to stay mounted through the operation.

4) What happened instead

I see in the system log that during the test systemd tries to perform an unmount operation on the mountpoint of the dm-device(s) that have lost an underlying path. The unmount fails, I assume because there is active IO at the time. However it should not be attempted in the first place.

I believe this is related to the bug that we discovered in RHEL and SLES that can be seen in this redhat commit:

https://github.com/lnykryn/systemd-rhel/commit/d77ced281c6d1f47b5dfc3abff6817d8f5756af9

Our testing of RHEL seems to indicate that this patch resolved our problem.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: systemd 229-3ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6
Uname: Linux 4.4.0-16-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
Date: Mon Apr 4 13:56:35 2016
MachineType: Dell Inc. PowerEdge R720
ProcEnviron:
 TERM=xterm
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-16-generic root=UUID=ab1330f8-0a76-4ba4-b2a2-a55f2b68b8c0 ro quiet splash vt.handoff=7
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /lib/systemd/system/systemd-timesyncd.service -> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
 [EXTENDED] /lib/systemd/system/rc-local.service -> /lib/systemd/system/rc-local.service.d/debian.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/22/2016
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.5.4
dmi.board.name: 0VWT90
dmi.board.vendor: Dell Inc.
dmi.board.version: A02
dmi.chassis.type: 23
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.5.4:bd01/22/2016:svnDellInc.:pnPowerEdgeR720:pvr:rvnDellInc.:rn0VWT90:rvrA02:cvnDellInc.:ct23:cvr:
dmi.product.name: PowerEdge R720
dmi.sys.vendor: Dell Inc.

[Peter (peter-redhat-bugs)]

This rule may be problematic:

SUBSYSTEM=="block", KERNEL!="ram*", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0"

The "SYSTEMD_READY=0" will cause automatic unmount of mountpoint that is on top of such DM device. It's even more problematic if this is used with multipath which sets DM_UDEV_DISABLE_OTHER_RULES_FLAG in case we have a CHANGE event that comes after DM multipath device reload when one of the paths is down or up (see also bug #1310022).

[Ryan (ryan-redhat-bugs)]

(In reply to Peter Rajnoha from comment #0)
> This rule may be problematic:
>
> SUBSYSTEM=="block", KERNEL!="ram*",
> ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0"
>
> The "SYSTEMD_READY=0" will cause automatic unmount of mountpoint that is on
> top of such DM device. It's even more problematic if this is used with
> multipath which sets DM_UDEV_DISABLE_OTHER_RULES_FLAG in case we have a
> CHANGE event that comes after DM multipath device reload when one of the
> paths is down or up (see also bug #1310022).

Hi Peter. Glad to hear that this has been identified as a problem. Obviously I wouldn't normally edit /usr/lib/udev/rules.d/*.rules files (I know changes will be reverted on update of systemd; perhaps it works like systemd unit files and I could put an override file of the same name in /etc/udev/rules.d?) but if I comment out that rule in 99-systemd.rules, is it sufficient to run `udevadm control --reload` to avoid being bitten by this issue?

[Peter (peter-redhat-bugs)]

(In reply to Ryan Sawhill from comment #1)
> Hi Peter. Glad to hear that this has been identified as a problem. Obviously
> I wouldn't normally edit /usr/lib/udev/rules.d/*.rules files (I know changes
> will be reverted on update of systemd; perhaps it works like systemd unit
> files and I could put an override file of the same name in
> /etc/udev/rules.d?) but if I comment out that rule in 99-systemd.rules, is
> it sufficient to run `udevadm control --reload` to avoid being bitten by
> this issue?

Yes, you can comment out that rule for now in /lib/udev/rules.d/99-systemd.rules and then on next systemd update, this will be overwritten by the new rules file which will have this removed officially.

And yes, udevadm control --reload should suffice.

[Peter (peter-redhat-bugs)]

However, I missed one point - we still need to be sure that systemd doesn't consider the device to be ready on ADD event because on ADD event, any DM device is still not ready - it needs to be loaded with teable and then resumed. So the rule should be:

UBSYSTEM=="block", ACTION=="add", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0"

(so it checks against 'ACTION=="add"')

[Peter (peter-redhat-bugs)]

*** Bug 1300453 has been marked as a duplicate of this bug. ***

[Peter (peter-redhat-bugs)]

*** Bug 1310022 has been marked as a duplicate of this bug. ***

[Ryan (ryan-redhat-bugs)]

Awesome! So to summarize for anyone following this from home, until new systemd packages including this fix are shipped, you can protect yourself from this issue by tweaking that line with sed:

  sed -i '/DM_UDEV_DISABLE_OTHER_RULES_FLAG/s|.*|SUBSYSTEM=="block", KERNEL!="ram*", ACTION=="add", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0"|' /usr/lib/udev/rules.d/99-systemd.rules

And reloading the rules:

  udevadm control --reload

[Matt (matt-redhat-bugs)]

Can you identify how far back this erroneous rule was introduced?

[Lukáš (luk-redhat-bugs)]

https://github.com/systemd/systemd/commit/b7cf1b68a79833411851fa547ac9b4906207c224

[Peter (peter-redhat-bugs)]

The systemd rule dates back to 2011 - so very old. But this had not manifested till we added further rules for multipath where we set flags for events which are coming from multipath device reload if multipath component underneath is down or it comes up (and hence multipath device needs to be reloaded). This is kind of event for which we really don't need to trigger all the existing rules again and trigger all scanning - it's just for the multipath dm device table reload which is transparent to any layer above or any mpath device user - so that's why we added DM_UDEV_DISABLE_OTHER_RULES_FLAG for such an event - to minimize the resource usage (in this case udev rule processing).

These new rules in multipath were added in RHEL7.0 then (which is also 2 years already!).

This problem has not manifested yet for other dm-based devices (like LVM) because these ones don't use the DM_UDEV_DISABLE_OTHER_RULES_FLAG after the device is set up and running - these require the scans and rules to be reevaluated if there's any reload compared to the multipath device where the content of the device is not changed during reloads when one of the paths is down or up.

[Lukáš (luk-redhat-bugs)]

pushed to staging ->
https://github.com/lnykryn/systemd-rhel/commit/d77ced281c6d1f47b5dfc3abff6817d8f5756af9
-> post

[Matt Schulte (gimpyestrada)]

This bug is being tracked in Netapp's internal bug tracking system: LSIP200858428

[Martin (martin-redhat-bugs)]

Please send such changes upstream too -- done in https://github.com/systemd/systemd/pull/3013 now.

[Martin Pitt (pitti)]

Upstreamed: https://github.com/systemd/systemd/pull/3013

[Lukáš (luk-redhat-bugs)]

Just for reference, here is the original pull request https://github.com/systemd/systemd/pull/2747

[Martin Pitt (pitti)]

Fix landed upstream, I imported it into our package.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 229-4ubuntu4

---------------
systemd (229-4ubuntu4) xenial; urgency=medium

  * 73-special-net-names.rules: Further refine ibmveth naming.

 -- Martin Pitt <email address hidden> Tue, 12 Apr 2016 12:06:30 +0200

[Matt Schulte (gimpyestrada)]

Can you comment on when or if this fixed package might be pushed to the Xenial repos?

[Martin Pitt (pitti)]

@Matt: it landed in xenial yesterday.

[Matt Schulte (gimpyestrada)]

I have run for a bit now and have not seen anymore erroneous unmounts. I'll call this one fixed and verified.

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2216.html