mirror of
git://sourceware.org/git/lvm2.git
synced 2024-10-27 18:55:19 +03:00
7a7b8a7778
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> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| 10-dm.rules.in | ||
| 11-dm-lvm.rules.in | ||
| 12-dm-permissions.rules | ||
| 13-dm-disk.rules.in | ||
| 69-dm-lvm-metad.rules.in | ||
| 95-dm-notify.rules.in | ||
| Makefile.in | ||