c072860593
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: |
||
---|---|---|
.clusterfuzzlite | ||
.github | ||
.semaphore | ||
catalog | ||
coccinelle | ||
docs | ||
factory | ||
hwdb.d | ||
LICENSES | ||
man | ||
mime | ||
mkosi.conf.d | ||
mkosi.images/system | ||
modprobe.d | ||
network | ||
pkg | ||
po | ||
presets | ||
rules.d | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
units | ||
xorg | ||
.clang-format | ||
.ctags | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.gitmodules | ||
.mailmap | ||
.packit.yml | ||
.pylintrc | ||
.vimrc | ||
.ycm_extra_conf.py | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
meson_options.txt | ||
meson.build | ||
meson.version | ||
mkosi.conf | ||
NEWS | ||
README | ||
README.md | ||
TODO |
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.