So, I looked into this a bit.
What you are seeing is actually expected or rather easy to explain:When emergency mode is triggered (either by a boot failure or adding emergency to the kernel command line), emergency.target is started and emergency.service as a result of it.
sysinit.target has "Conflicts=emergency.service emergency.target"So, whenever something triggers the start of sysinit.target, it will in turn stop emergency.{service,target}
Basically, all units aside from early boot services have an explicit dependency on sysinit.target (see e.g. systemctl show -p Requires -p After anacron.service)
So, by starting such a service, you also trigger the start of sysinit.target, which in turn stops emergency.{service,target}
This has been raised a while ago and fix committed https://github.com/systemd/systemd/pull/6765 Unfortunately, this was reverted, as it caused a dependency loop https://github.com/systemd/systemd/pull/6904 After that, nothing has happened anymore regarding this issue afaics. Would you be willing to file an upstream bug report?Maybe there is a way, to find a solution for this without causing a regression.
For the time being, you might consider using single/rescue mode. It doesn't seem to have such a conflicts with sysinit.target.
Regards, Michael
OpenPGP_signature
Description: OpenPGP digital signature
