Re: [systemd-devel] Method to solve a "ordering cycle"
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"
Am 09/08/2015 um 08:51 AM schrieb Daurnimator: > On 8 September 2015 at 16:16, Daniel Spannbauer <d...@marco.de> 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"
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"
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
[systemd-devel] Method to solve a "ordering cycle"
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
[systemd-devel] Service always started as root
Hello, I've configured a service which should start as a specific user. But the service is always started as root. Here is my service-file: [Unit] Description=Autologin After=getty.target [Service] ExecStart=/usr/bin/autologin PAMName=login Name=daniel Group=users [Install] WantedBy=multi-user.target The service starts as expected, but as user root. The script /usr/bin/autologin starts an X-Server on vt08, the script has permissions 744. Any ideas why the service is started as root? Regards Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email d...@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Convert Inittab-Entry to systemd
Hello, till now we had the following entry in the /etc/inittab: X1:5:once:/bin/su - user -c xinit /home/user/.xsession -- /usr/bin/X :1 vt08 -r -br 1/tmp/X1.log 21 On our new system systemd is now standard. So I tried to convert this in a systemd.servce: [Unit] Description=Autologin After=getty.target [Service] ExecStart=/bin/su - user -c xinit /home/user/.xsession -- /usr/bin/X :1 vt08 -r -br -dpms -s off 1/tmp/X1.log 21 Restart=always [Install] WantedBy=multiuser.target I stored it at /etc/systemd/system as autologin.service, enabled it and started it. WOrks as expected. But not at a system-start. There is nothing about the failed autologin at the system-messages. systemctl status autologin.service says: autologin.service - Autologin Loaded: loaded (/etc/systemd/system/autologin.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/autologin.service I can't find any messages why the service failed. Any hints about this? Regards Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email d...@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
