mirror of
https://github.com/systemd/systemd
synced 2024-09-06 08:46:19 +00:00
![]() Device mapper devices are set up in multiple steps. The first step, which generates the initial "add" event, only creates an empty container, which is useless for higher layers. SYSTEMD_READY should be set to 0 on this event to avoid premature device activation. The event that matters is the "activation" event: the first "change" event on which DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 is not set. When this event arrives, the device is ready for being scanned by blkid and similar tools, and for being activated by systemd. Intermittent events with DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 should be ignored as far as systemd or higher-level block layers are concerned. Previous device properties and symlinks should be preserved: the device shouldn't be scanned or activated, but shouldn't be deactivated, either. In particular, SYSTEM_READY shouldn't be set to 0 if it wasn't set before, because that might cause mounted file systems to be unmounted. Such intermittent events may occur any time, before or after the "activation" event. DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 can have multiple reasons. One possible reason is that the device is suspended. There are other reasons that depend on the device-mapper subsystem (LVM, multipath, dm-crypt, etc.). The current systemd rule set 1) sets SYSTEMD_READY=0 if DM_UDEV_DISABLE_OTHER_RULES_FLAG is set in "add" events; 2) imports SYSTEMD_READY from the udev db if DM_SUSPENDED is set, and jumps to systemd_end; 3) sets SYSTEMD_READY=1, otherwise. This logic has several flaws: * 1) can cause file systems to be unmounted if an coldplug event arrives while a file system is suspended. This rule shouldn't be applied for coldplug events or in general, "synthetic" add events; * 2) evaluates DM_SUSPENDED=1, which is a device-mapper internal property. It's wrong to infer that a device is accessible if DM_SUSPENDED=0. The jump to systemd_end may cause properties and/or symlinks to be lost; * 3) is superfluous, because SYSTEMD_READY=1 is equivalent with SYSTEMD_READY being unset, and can create the wrong impression that the device was explicitly activated. This patch fixes the logic as follows: - apply 1) only if DM_NAME is empty, which is only the case for the first "genuine add" event; - change 2) to use DM_UDEV_DISABLE_OTHER_RULES_FLAG instead of DM_SUSPENDED, and remove the GOTO directive; - remove 3). Fixes: |
||
---|---|---|
.. | ||
50-udev-default.rules.in | ||
60-autosuspend.rules | ||
60-block.rules | ||
60-cdrom_id.rules | ||
60-dmi-id.rules | ||
60-drm.rules | ||
60-evdev.rules | ||
60-fido-id.rules | ||
60-infiniband.rules | ||
60-input-id.rules | ||
60-persistent-alsa.rules | ||
60-persistent-input.rules | ||
60-persistent-media-controller.rules | ||
60-persistent-storage-mtd.rules | ||
60-persistent-storage-tape.rules | ||
60-persistent-storage.rules.in | ||
60-persistent-v4l.rules | ||
60-sensor.rules | ||
60-serial.rules | ||
64-btrfs.rules.in | ||
70-camera.rules | ||
70-joystick.rules | ||
70-memory.rules | ||
70-mouse.rules | ||
70-power-switch.rules | ||
70-touchpad.rules | ||
70-uaccess.rules.in | ||
71-seat.rules.in | ||
73-seat-late.rules.in | ||
75-net-description.rules | ||
75-probe_mtd.rules | ||
78-sound-card.rules | ||
80-drivers.rules | ||
80-net-setup-link.rules | ||
81-net-dhcp.rules | ||
82-net-auto-link-local.rules | ||
90-iocost.rules | ||
90-vconsole.rules.in | ||
99-systemd.rules.in | ||
meson.build | ||
README |
Files in this directory contain configuration for systemd-udevd.service, a daemon that manages symlinks to device nodes, permissions of devices nodes, emits device events for userspace, and renames network interfaces. See man:udev(7) for an overview of the configuration file format, and man:systemd-udevd.service(8) for a description of service itself. Use 'systemd-analyze cat-config udev/rules.d' to display the effective config.