Bug 1312011 - Fix rule setting SYSTEMD_READY=0 for DM devices (like multipath) which may cause improper automatic unmounts
Fix rule setting SYSTEMD_READY=0 for DM devices (like multipath) which may ca...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
7.3
All Linux
urgent Severity high
: rc
: ---
Assigned To: systemd-maint
Branislav Blaškovič
: ZStream
: 1300453 1310022 (view as bug list)
Depends On:
Blocks: 1269644 1310022 1314693
  Show dependency treegraph
 
Reported: 2016-02-25 09:04 EST by Peter Rajnoha
Modified: 2017-01-31 05:44 EST (History)
10 users (show)

See Also:
Fixed In Version: systemd-219-20.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1314693 (view as bug list)
Environment:
Last Closed: 2016-11-03 20:52:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2191151 None None None 2016-10-25 03:14 EDT
Red Hat Knowledge Base (Solution) 2693291 None None None 2016-10-25 03:15 EDT

  None (edit)
Description Peter Rajnoha 2016-02-25 09:04:19 EST
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).
Comment 1 Ryan Sawhill 2016-02-25 14:01:04 EST
(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?
Comment 2 Peter Rajnoha 2016-02-26 02:58:08 EST
(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.
Comment 3 Peter Rajnoha 2016-02-26 03:19:01 EST
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"')
Comment 4 Peter Rajnoha 2016-02-26 03:33:36 EST
*** Bug 1300453 has been marked as a duplicate of this bug. ***
Comment 5 Peter Rajnoha 2016-02-26 03:38:11 EST
*** Bug 1310022 has been marked as a duplicate of this bug. ***
Comment 6 Ryan Sawhill 2016-02-26 09:37:05 EST
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
Comment 7 Matt Schulte 2016-02-26 14:29:05 EST
Can you identify how far back this erroneous rule was introduced?
Comment 9 Peter Rajnoha 2016-02-29 03:36:41 EST
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.
Comment 11 Lukáš Nykrýn 2016-03-01 09:50:21 EST
pushed to staging ->
https://github.com/lnykryn/systemd-rhel/commit/d77ced281c6d1f47b5dfc3abff6817d8f5756af9
-> post
Comment 15 Martin Pitt 2016-04-11 05:02:29 EDT
Please send such changes upstream too -- done in https://github.com/systemd/systemd/pull/3013 now.
Comment 16 Lukáš Nykrýn 2016-04-11 07:07:20 EDT
Just for reference, here is the original pull request https://github.com/systemd/systemd/pull/2747
Comment 19 errata-xmlrpc 2016-11-03 20:52:10 EDT
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

Note You need to log in before you can comment on or make changes to this bug.