On Thu, 28.03.13 12:22, Belal, Awais ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
