Bug 40080

Summary: activating dbus.service launches complete boot into graphical mode
Product: systemd Reporter: Simon Peeters <peeters.simon>
Component: generalAssignee: Lennart Poettering <lennart>
Status: NEW --- QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: dmesg of the problem

Description Simon Peeters 2011-08-14 07:45:12 UTC
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

Comment 1 Lennart Poettering 2011-08-30 18:47:37 UTC
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.
Comment 2 Simon Peeters 2011-08-31 06:11:39 UTC
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)
Comment 3 Simon Peeters 2011-08-31 08:49:22 UTC
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
Comment 4 Zbigniew Jedrzejewski-Szmek 2012-07-30 10:28:33 UTC
[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.