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

[Daniel Spannbauer]

Am 09/07/2015 um 02:29 PM schrieb 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 )
>

Hello,

another short question: Can I test the system without rebooting it to
find ordering cycles?

Regards

Daniel