[systemd-devel] A newbie question regarding ordering cycles

[Lennart Poettering]

On Thu, 28.03.13 12:22, Belal, Awais (Awais_Belal at mentor.com) wrote:

> 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

So, basic.target wants to be after sockets.target, which wants to be
after dbus.socket, which wants to be after sysinit.target, which wants
to be after run-postinsts.service which wants to be after
basic.target. And that of course can't work, there you have your
cycle. I figure run-postinsts.service is your own service? And you tried
to order it before sysinit.target, right?

Note that service units by default get implicitly ordered after
basic.target, since that is what most units need. You can turn this off
with DefaultDependencies=no. With other words: all early-boot services
need to turn this of.

> 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.

Well, it dbus.service might get pulled back in later, but ofono/connman aren't.

> 
>   1.  How can such problems be disected and is there a way for knowing
>   the dependency graph?

Well, the output should already tell you enough in this case. i.e you
just have to read it top to bottem, as shown above.

>   2.  The ordering cycle was broken at dbus.socket/start, why aren't
>   the other services tried out after that?

Well, systemd currently picks any of them, because it's a loop and they
hence there is none a better choice then the others... So it takes one
and removes it, in the hope it makes things better...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.