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?
signature.asc
Description: OpenPGP digital signature
