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 systemd29-1.1(debian)
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[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.StartUnit() on /org/freedesktop/systemd1 [ 37.349351] systemd[1]: 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.