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