when i boot into emergency.target and start dbus.service, the whole system boots (into default.target, which is graphical in my case)
how to reproduce:
boot with systemd.unit=emergency.target
systemctl start dbus.service
watch the whole system boot
Hmm, it would be good if you could boot with "systemd.log_level=debug systemd.log_target=kmsg log_buf_len=2M" on the kernel cmdline. Then, repeat your test case and attach the contents of dmesg after the boot here. This should give us a hint why the rest of the system got pulled in by dbus.
Created attachment 50755 [details]
dmesg of the problem
added the log (cut out the unnecessary pieces)
when at line 100 dbus.service is added to the queue everything seems fine to me
but then things just get bad, when suddenly at line 340
[ 37.349305] systemd: Got D-Bus request: org.freedesktop.systemd1.Manager.StartUnit() on /org/freedesktop/systemd1
[ 37.349351] systemd: Trying to enqueue job graphical.target/start/fail
from which i have NO idea were it comes from (tried grep graphical /bin/* /sbin/* /usr/bin/* /usr/sbin/* /etc/init.d/* /lib/lsb/* but none of the programs returned have anything to do with bootup )
i am actually unsure if this happens only with dbus.service, will try a couple more and see what i can get out of it
PS: meanwhile i have systemd 33 installed (upstream version, since debian unstable is lagging behind 4 releases)
after looking a bit around i found:
dbus.service pulls in sysinit.target
sysinit.target has Conflicts=emergency.service emergency.target
emergncy.service has ExecStopPost=/bin/systemctl --fail --no-block default
when commenting the Conflicts line from sysinit.target everything works ass expected
[Just confirmed this behaviour with systemd-187.]
I agree with Simon's solution: let's remove the 'Conflicts' line from sysinit.target. Actually, sysinit.target shouldn't conflict with emergency mode. One could try to bring up the system in steps, starting from emergency mode, and then pulling in stuff by hand, including sysinit.target.
If the Conflicts line is removed, then we lose the behaviour that 'systemctl default' kills the emergency shell. One way to keep that behaviour, would be to change 'systemctl default' to run 'isolate default.target' instead of just 'start default.target'. I'm not sure why 'systemctl default' is different from 'systemctl emergency' or 'systemctl rescue', that it runs 'start' not 'isolate'. It seems logical to always 'isolate'.
A different approach would be to tell the user to close the emergency shell by herself, by pressing ^D when done.