Michal Sekletár
882f5f429e
Previously we would call umount from ExecStartPost= of systemd-cryptsetup instance in order to get rid of the keydev mount (i.e. filesystem containing keyfile). Let's generate unit to handle umount. Making this symmetrical (both mount and umount of keydev are handled by units) fixes the problem with lingering keydev mounts. Motivation for the change is the issue where keydev mount would stay around even if device was successfully unlocked and mount is no longer needed. That could happen previously because when generator options are not prefixed with "rd." we run generators twice (e.g. rd.luks.key=...). In such case disk is unlocked in initramfs phase of boot (assuming the initrd image contains the generator and is able to handle unlocking of LUKS devices). After switchroot we however enqueue start job for systemd-cryptsetup instance (because units are regenerated second time) and that pulls in its dependencies into transaction. Later the main systemd-cryptsetup unit not actually started since it is already active and has RemainaAfterExit=yes. Nevertheless, dependencies get activated and keydev mount is attached again. Because previously we called umount from ExecStartPost= of systemd-cryptsetup instance the umount is not called second time and keydev filesystem stays lingering.
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 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 or join our IRC channel.
Stable branches with backported patches are available in the stable repo.