On Thu, Mar 28, 2013 at 7:07 AM, Colin Guthrie <[email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
