[systemd-devel] A newbie question regarding ordering cycles
Colin Guthrie
gmane at colin.guthr.ie
Thu Mar 28 07:07:38 PDT 2013
'Twas brillig, and Belal, Awais at 28/03/13 12:22 did gyre and gimble:
> Hi Guys,
>
> Just a newbie question as I am not much familiar with systemd yet. While
> setting up a system I have systemd-195 running but some of the services
> are not launched properly. I get the following:
>
> *systemd[1]: Found ordering cycle on basic.target/start*
> *systemd[1]: Walked on cycle path to sockets.target/start*
> *systemd[1]: Walked on cycle path to dbus.socket/start*
> *systemd[1]: Walked on cycle path to sysinit.target/start*
> *systemd[1]: Walked on cycle path to run-postinsts.service/start*
> *systemd[1]: Walked on cycle path to basic.target/start*
> *systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start*
> *systemd[1]: Deleting job ofono.service/start as dependency of job
> dbus.socket/start*
> *systemd[1]: Deleting job dbus.service/start as dependency of job
> dbus.socket/start*
> *systemd[1]: Deleting job connman.service/start as dependency of job
> dbus.socket/start*
>
> Systemd is running in SysV compatibility mode. The odd thing here for me
> is once the system finishes booting I can see that dbus.service is up
> (through systemctl) but ofono and connman are never started although I
> can start them manually through systemctl.
>
> 1. How can such problems be disected and is there a way for knowing the
> dependency graph?
> 2. The ordering cycle was broken at dbus.socket/start, why aren't the
> other services tried out after that?
>
> BR,
> Awais
As Frederic already said in his reply, I've found the most common case
for ordering cycles is the lack of LSB headers in legacy sysvinit scripts.
When there are no LSB headers systemd has to use the number in the
symlink (the S??fooo bit) to determine the ordering.
These orders frequently cause cycles.
Another improvement to the cycle breaking logic could be to somehow boot
out non-native units first (ideally non-LSB, followed by LSB, followed
by native if sysvinit compatibility is compiled in).
It's perhaps not overly clean to implement tho'.
The "cleanest" solution is of course just to migrate away from sysvinit
in any shape or form :)
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the systemd-devel
mailing list