Ubuntu
systemd package

Udev rule causes automatic incorrect unmount of dm device

Bug #1565969 reported by Matt Schulte
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Fedora)
Fix Released
High
systemd (Ubuntu)
Fix Released
Medium
Martin Pitt

Bug Description

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.

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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).

Revision history for this message
In , Ryan (ryan-redhat-bugs) wrote :

(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?

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

(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.

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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"')

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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

Revision history for this message
In , Ryan (ryan-redhat-bugs) wrote :

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

Revision history for this message
In , Matt (matt-redhat-bugs) wrote :

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

Revision history for this message
In , Lukáš (luk-redhat-bugs) wrote :

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

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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.

Revision history for this message
In , Lukáš (luk-redhat-bugs) wrote :

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

Revision history for this message
Matt Schulte (gimpyestrada) wrote :
Revision history for this message
Matt Schulte (gimpyestrada) wrote :

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

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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

Revision history for this message
Martin Pitt (pitti) wrote :

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

Changed in systemd (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: New → In Progress
Revision history for this message
In , Lukáš (luk-redhat-bugs) wrote :

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

Revision history for this message
Martin Pitt (pitti) wrote :

Fix landed upstream, I imported it into our package.

Changed in systemd (Ubuntu):
importance: Undecided → Medium
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Matt Schulte (gimpyestrada) wrote :

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

Revision history for this message
Martin Pitt (pitti) wrote :

@Matt: it landed in xenial yesterday.

Revision history for this message
Matt Schulte (gimpyestrada) wrote :

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

Revision history for this message
In , errata-xmlrpc (errata-xmlrpc-redhat-bugs) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in systemd (Fedora):
importance: Unknown → High
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.