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 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/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/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"
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
[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
Re: [systemd-devel] Convert Inittab-Entry to systemd
Am 08/27/2013 07:50 PM, schrieb Kok, Auke-jan H: > On Tue, Aug 27, 2013 at 9:38 AM, Colin Guthrie wrote: >> Also I don't think this will properly handle session registration will >> it? There is nothing here that registers the session - no pam configs to >> include pam_systemd etc. > > nope > >> I think you would need some kind of PAMName= attribute here to also >> handle that (man systemd.exec(5)). Obviously the /etc/pam.d/ stuff would >> need to be configured accordingly with appropriate permissions (I >> presume) to allow autologin but also ensure the pam_systemd stuff is >> configured properly. Never tried this kind of autologin but I don't >> think I'm talking too much nonsense :D > > PAMName=login should just work here. > Hello, I tried it with "PAMName"...the service did not start at boot or when started manually. See the logs below... - 2013-07-12T01:27:54.651603-04:00 instalz11 systemd[1]: Accepted connection on private bus. 2013-07-12T01:27:54.652862-04:00 instalz11 systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.StartUnit() on /org/freedesktop/systemd1 2013-07-12T01:27:54.653976-04:00 instalz11 systemd[1]: Trying to enqueue job autologin.service/start/replace 2013-07-12T01:27:54.659879-04:00 instalz11 systemd[1]: Installed new job autologin.service/start as 328 2013-07-12T01:27:54.661088-04:00 instalz11 systemd[1]: Enqueued job autologin.service/start as 328 2013-07-12T01:27:54.661894-04:00 instalz11 systemd[1]: Starting marco Autologin... 2013-07-12T01:27:54.662595-04:00 instalz11 systemd[1]: About to execute /usr/bin/xinit /home/xalz/.xsession -- /usr/bin/X :1 vt08 -r -br -dpms -s off 2013-07-12T01:27:54.663403-04:00 instalz11 systemd[1]: Forked /usr/bin/xinit as 2422 2013-07-12T01:27:54.664222-04:00 instalz11 systemd[1]: autologin.service changed failed -> running 2013-07-12T01:27:54.664933-04:00 instalz11 systemd[1]: Job autologin.service/start finished, result=done 2013-07-12T01:27:54.665670-04:00 instalz11 systemd[1]: Started marco Autologin. 2013-07-12T01:27:54.666388-04:00 instalz11 systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.GetUnit() on /org/freedesktop/systemd1 2013-07-12T01:27:54.667097-04:00 instalz11 systemd[1]: Got D-Bus request: org.freedesktop.DBus.Properties.Get() on /org/freedesktop/systemd1/unit/autologin_2eservice 2013-07-12T01:27:54.667791-04:00 instalz11 systemd[2422]: Failed at step PAM spawning /usr/bin/xinit: Operation not permitted 2013-07-12T01:27:54.668226-04:00 instalz11 systemd: pam_warn(xalz:account): function=[pam_sm_acct_mgmt] service=[xalz] terminal=[] user=[xalz] ruser=[] rhost=[] 2013-07-12T01:27:54.673326-04:00 instalz11 systemd[1]: Unit autologin.service entered failed state 2013-07-12T01:27:54.674982-04:00 instalz11 systemd[1]: Accepted connection on private bus. 2013-07-12T01:27:54.675811-04:00 instalz11 systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Agent.Released() on /org/freedesktop/systemd1/agent 2013-07-12T01:27:54.676530-04:00 instalz11 systemd[1]: autologin.service: cgroup is empty 2013-07-12T01:27:54.677264-04:00 instalz11 systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local -- Here is the service-file: [Unit] Description=marco Autologin After=getty.target [Service] ExecStart=/usr/bin/xinit /home/xalz/.xsession -- /usr/bin/X :1 vt08 -r -br -dpms -s off User=xalz PAMName=xalz Group=alz Environment="PATH=/usr/uti/sys:/usr/uti:/usr/uti/mcu::/usr/uti/sys:/usr/uti:/usr/uti/mcu:/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/uti/inst:/usr/uti/inst" [Install] WantedBy=multi-user.target any ideas? 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 2>&1 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 2>&1 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