Re: [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 (d...@marco.de) wrote:
>>
>>> Am 09/06/2015 um 03:50 PM schrieb Lennart Poettering:
 On Wed, 02.09.15 17:08, Daniel Spannbauer (d...@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

>>> H,
>>>
>>> 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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daniel Spannbauer]

Am 09/08/2015 um 08:51 AM schrieb Daurnimator:
> On 8 September 2015 at 16:16, Daniel Spannbauer  wrote:
>> Can I test the system without rebooting it to
>> find ordering cycles?
> Try `systemd-analyze verify myfile.someunit`
Hmmm, this works only for one service. Can I also analyze the whole
systemd-start-process?

Regards

Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daurnimator]

On 8 September 2015 at 16:16, Daniel Spannbauer  wrote:
> Can I test the system without rebooting it to
> find ordering cycles?

Try `systemd-analyze verify myfile.someunit`
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daniel Spannbauer]

Am 09/06/2015 um 03:50 PM schrieb Lennart Poettering:
> On Wed, 02.09.15 17:08, Daniel Spannbauer (d...@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
>
H,

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


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

Regards

Daniel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Alexander E. Patrakov]

07.09.2015 11:10, Daniel Spannbauer wrote:

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


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


None of the services in particular generates the trouble. The trouble is 
from the fact that they all say, collectively, that they need each 
other. To troubleshoot this, you would need to answer these questions:


Do you mount any remote filesystem using the server name, as opposed to 
its IP address?


Do you really need a local instance of named?

Does the local named actually get any of its zones from LDAP?

Does your LDAP server use any databases stored on a remote filesystem?

Do you actually use the owncloud mount?

--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mon, 07.09.15 08:10, Daniel Spannbauer (d...@marco.de) wrote:

> Am 09/06/2015 um 03:50 PM schrieb Lennart Poettering:
> > On Wed, 02.09.15 17:08, Daniel Spannbauer (d...@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
> >
> H,
> 
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [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 (d...@marco.de) wrote:
>
>> Am 09/06/2015 um 03:50 PM schrieb Lennart Poettering:
>>> On Wed, 02.09.15 17:08, Daniel Spannbauer (d...@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
>>>
>> H,
>>
>> 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 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Wed, 02.09.15 17:08, Daniel Spannbauer (d...@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

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daniel Spannbauer]

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?

regards

Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel