]> sourceware.org Git - lvm2.git/commit
udev: keep systemd vars on change event in 69-dm-lvm-metad.rules for systemd reload
authorMartin Wilck <mwilck@suse.com>
Tue, 17 Apr 2018 09:38:12 +0000 (11:38 +0200)
committerPeter Rajnoha <prajnoha@redhat.com>
Tue, 17 Apr 2018 09:38:12 +0000 (11:38 +0200)
commit7a7b8a7778aace88c967ee8285485c494ce1f3f8
treeb1a2a62aea590d6537948ba5423f456c137a332a
parent99bfbbf229acf4548f1ffc06625f464dc0ae4ca4
udev: keep systemd vars on change event in 69-dm-lvm-metad.rules for systemd reload

The current logic that avoids setting SYSTEMD_ALIAS and SYSTEMD_WANTS
on "change" events is flawed in the default "systemd background job"
configuration. For systemd, it's important that device properties don't
change spuriously.

If an "add" event starts lvm2-pvscan@.service for a device, and a
"change" event follows, removing SYSTEMD_ALIAS and SYSTEMD_WANTS from the
udev db, information about unit dependencies between the device and the
pvscan service can be lost in systemd, in particular if the daemon
configuration is reloaded.

Steps to reproduce problem:

- create a device with an LVM PV
- remove device
- add device (generates "add" and "change" uevents for the device)
  (at this point SYSTEMD_ALIAS and SYSTEMD_WANTS are clear in udev db)
- systemctl daemon-reload
  (systemd reloads udev db)
- vgchange -a n
- remove device

=> the lvm2-pvscan@.service for the device is still active although the
device is gone.

- add device again

=> the PV is not detected, because systemd sees the lvm2-pvscan@.service
as active and thus doesn't restart it.

The original purpose of this logic was to avoid volumes being scanned
over and over again. With systemd background jobs, that isn't necessary,
because systemd will not restart the job as long as it's active.

Signed-off-by: Martin Wilck <mwilck@suse.com>
WHATS_NEW
udev/69-dm-lvm-metad.rules.in
udev/Makefile.in
This page took 0.029963 seconds and 5 git commands to generate.