If for any reason local-fs.target fails at startup while a password is
requested by systemd-cryptsetup@.service, we end up with the emergency shell
competing with systemd-ask-password-console.service for the console.
This patch makes sure that:
- systemd-ask-password-console.service is stopped before entering in emergency
mode so it won't make any access to the console while the emergency shell is
running.
- systemd-ask-password-console.path is also stopped so any attempts to restart
systemd-cryptsetup in the emergency shell won't restart
systemd-ask-password-console.service and kill the emergency shell.
- systemd-ask-password-wall.path is stopped so
systemd-ask-password-wall.service won't be started as this service pulls
the default dependencies in.
Fixes: #10131
Description=Dispatch Password Requests to Console Directory Watch
Documentation=man:systemd-ask-password-console.service(8)
DefaultDependencies=no
-Conflicts=shutdown.target
+Conflicts=shutdown.target emergency.service
After=plymouth-start.service
Before=paths.target shutdown.target cryptsetup.target
ConditionPathExists=!/run/plymouth/pid
Description=Dispatch Password Requests to Console
Documentation=man:systemd-ask-password-console.service(8)
DefaultDependencies=no
-Conflicts=shutdown.target
+Conflicts=shutdown.target emergency.service
After=plymouth-start.service systemd-vconsole-setup.service
Before=shutdown.target
ConditionPathExists=!/run/plymouth/pid
Description=Forward Password Requests to Wall Directory Watch
Documentation=man:systemd-ask-password-console.service(8)
DefaultDependencies=no
-Conflicts=shutdown.target
+Conflicts=shutdown.target emergency.service
Before=paths.target shutdown.target cryptsetup.target
[Path]