[systemd-devel] A newbie question regarding ordering cycles
Kok, Auke-jan H
auke-jan.h.kok at intel.com
Thu Mar 28 09:50:55 PDT 2013
On Thu, Mar 28, 2013 at 7:07 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> '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: Found ordering cycle on basic.target/start*
>> *systemd: Walked on cycle path to sockets.target/start*
>> *systemd: Walked on cycle path to dbus.socket/start*
>> *systemd: Walked on cycle path to sysinit.target/start*
>> *systemd: Walked on cycle path to run-postinsts.service/start*
>> *systemd: Walked on cycle path to basic.target/start*
>> *systemd: Breaking ordering cycle by deleting job dbus.socket/start*
>> *systemd: Deleting job ofono.service/start as dependency of job
>> *systemd: Deleting job dbus.service/start as dependency of job
>> *systemd: Deleting job connman.service/start as dependency of job
>> 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?
> 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 :)
BTW, both ofono and connman projects are systemd-enabled and will
install service files (check the configure flags) that should work
properly with systemd.
More information about the systemd-devel