Bug#752259: systemd: User interaction regarding Ordering cycle found: D-Bus System Message Bus Socket

[Michael Biebl]

Am 21.06.2014 17:41, schrieb Peter Gervai:
> Reboot resulted an interesting view: endless rapid (10s per second) messages
> about 
> [SKIP] ordering cycle found: D-Bus System Message Bus Socket
> and that's all. Obviously nothing can be done, Ctrl-Alt-Del not yet
> functioning, no further messages, machine looping. 
> 
> RESET button is not my faviourite part of the machine. Required here.
> 
> After several reboots, some tricks and guesswork resulted that maybe
> dbus.docket/start vs. sockets.target/start match was ongoing.
> 
> First, this should not happen. systemd seemed to try to remove random jobs
> to break the (same) loop, then possibly realising that it'd break the system and
> try to break another job, then start again. It should not keep breaking
> the _same_ loop infinite times. Some counters would help.

Agreed. We are still investigating why the dep cycle breaking doesn't
work under certain circumstances, but haven't found the root cause yet.

> The loop was "broken" by using a rescue disk and _EMPTYING_ /etc/init.d/
> completely. I'm not yet finished about figuring out which components were
> causing the loop, but it wasn't "chkconfig" (tried that first) and were not
> unessentials (I have tried to move them first without luck). 

Do you have a copy/backup around of /etc/init.d (or rather /etc/rc?.d/).
This could give us a clue which service caused the dep cycle.


> In the meantime system was unstartabl again when systemd have failed to mount
> everything in fstab, which was skipped in sysvinit; one line had syntax
> error (fs type was missing to there was a bad fs mount option) and other was
> referring to a nonexisting mount directory. These turned out to be fatal for
> systemd, which offered singleuser root shell for that. 

Yeah, systemd is more strict regarding missing devices in fstab and
drops you into a rescue shell in that case.
I'm not sure if we can detect whether a fstab line is incorrect, but
what me might detect rather reliably is whether a device in /etc/fstab
is missing and we do plan to add a preinst check to systemd-sysv which
would warn about such issues (and how to fix it).

In summary, there are three issues:

1/ a (faulty) service causing a dep cycle
2/ the dep cycle resolver being broken under certain circumstances (this
doesn't happen always).
3/ the different fstab behaviour.

2/ needs to be fixed in the actual package shipping that SysV or systemd
service file. For that we need to identify that service.

1/ is still under investigation.

3/ we intend to handle via the preinst check (even though it can't
detect all cases of broken fstab lines)




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140622/37dbb8de/attachment-0002.sig>