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 >>>> >>> 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
