[systemd-devel] A newbie question regarding ordering cycles

[Kok, Auke-jan H]

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[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 :)

BTW, both ofono and connman projects are systemd-enabled and will
install service files (check the configure flags) that should work
properly with systemd.

Auke