[systemd-devel] A newbie question regarding ordering cycles

[Lennart Poettering]

On Thu, 28.03.13 13:47, Frederic Crozat (fcrozat at suse.com) wrote:

> Le jeudi 28 mars 2013 à 12:22 +0000, Belal, Awais a écrit :
> > 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
> 
> Based on experience, the problem usually lays in the .service listed in
> the cycle, in your case "run-postinsts.service". It has probably
> incorrect (or no) LSB dependencies.

Well, newer systemd versions do not allow early-boot SysV scripts
anyway. There never was a standard way to do it. SysV scripts are only
supported for normal services.

> systemd could be improved to not drop dbus.socket in its ordering cycle
> break algorithm (there were some discussions some time ago on IRC) but
> it hasn't happened yet.

Well, I am not going to hardcode that dbus.socket is always the last one
to be removed. There are certainly some changes possible (for example,
kill the unit with the newest file modification date, as that is likely
to be the most recently added that is borked), but tha's all black
magic...

I mean, this is generally not an end-user problem, more one that system
integrators might run into, i.e. the folks who actually fiddle with
early boot, and who write non-trivial unit files, so maybe trying to
magically fix a broken situation isn't really worth it, but rather
improve the debugging...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.