Bug 40080

Summary:	activating dbus.service launches complete boot into graphical mode
Product:	systemd	Reporter:	Simon Peeters <peeters.simon>
Component:	general	Assignee:	Lennart Poettering <lennart>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
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

systemd29-1.1(debian)

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.