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

[Daniel Spannbauer]

Am 09/07/2015 um 01:56 PM schrieb 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
>
Hello Lennart,

yes, this helps a lot. I don't need a local named, but didn't realize
that it was started.
But I will also look at the other dependencies.

Thanks al lot (also to Alexander E. Patrakov )

Regards

Daniel