[systemd-devel] Method to solve a "ordering cycle"

[Lennart Poettering]

On Mon, 07.09.15 08:10, Daniel Spannbauer (ds at marco.de) wrote:

> Am 09/06/2015 um 03:50 PM schrieb Lennart Poettering:
> > On Wed, 02.09.15 17:08, Daniel Spannbauer (ds at marco.de) wrote:
> >
> >> Hello,
> >>
> >> I often have a ordering cycle so a service is deleted at boot.
> >>
> >> Is there a standard way of getting rid of that cycles or to find the
> >> cause of them?
> > Well, when systemd finds one of these cyclic ordering dependencies it will
> > print your the full chain of it in the logs. It's not too difficult to
> > read that actually, as it starts with one unit, and then shows you the
> > next one that is ordered after it, and then the next one, and so on,
> > until it comes back to the original one which is supposed to be after
> > that last one... Now it's just a matter to figure out where to break
> > the cycle and drop the ordering dependency.
> >
> > Lennart
> >
> Hmmmm,
> 
> the following log isfrom one of my machines:
> 
> Sep 04 14:56:04 fry systemd[1]: Activating default unit: default.target
> Sep 04 14:56:04 fry systemd[1]: Trying to enqueue job
> multi-user.target/start/replace
> Sep 04 14:56:04 fry systemd[1]: ESC[1;39mFound ordering cycle on
> remote-fs-pre.target/startESC[0m
> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
> nss-lookup.target/start
> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to named.service/start
> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to ldap.service/start
> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
> remote-fs.target/start
> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
> owncloud_all.mount/start
> Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to
> remote-fs-pre.target/start
> Sep 04 14:56:04 fry systemd[1]: ESC[1;31mBreaking ordering cycle by
> deleting job nss-lookup.target/startESC[0m
> Sep 04 14:56:04 fry systemd[1]: Deleting job postfix.service/start as
> dependency of job nss-lookup.target/start

Your ordering cycle is this one, reading the logs from top to bottom:

     remote-fs-pre.target → nss-lookup.target → named.service →
     ldap.service → remote-fs.target → owncloud_all.mount →
     remote-fs-pre.target

Or in other words: named.target wants to be run before
nss-lookup.target, which wants to be run beofre remote-fs-pre.target,
which through owncloud_all.mount wants to run before remote-fs.target,
which wants to run before ldap.service which wants to run before
named.service, and that's your ordering cycle. 

systemd cannot fulfill this ordering of course. It cannot run named
both before and after your remote mount owncloud_all.mount. This is
logically impossible, of course.

> Which service generates the trouble and what should I do to get rid
> of this?

Well, you have to break the cycle somewhere. You probably should
remove the ordering dep either 

1) between nss-lookup.target and named.service, or 
2) between named.service and ldap.service, or 
3) between ldap.service and remote-fs.target.

Pick one, depending on what you need.

Unless you have a good reason to keep this specific ordering
dependency, I'd probably remove the ordering #3. In fact, I'd go as
far as file a bug against ldap and ask them to remove the dep in their
package, referring back to this ML thread. It's an ordering dependency
people should probably add if they need it, but not be in place by
default, since it's probably common to combine named and ldapd in one
installation.

Hope this is useful,

Lennart

-- 
Lennart Poettering, Red Hat