Re: [systemd-devel] A newbie question regarding ordering cycles
Thanks a lot guys, this clears up quite a bit of confusion :) BR, Awais From: systemd-devel-bounces+awais_belal=mentor@lists.freedesktop.org [systemd-devel-bounces+awais_belal=mentor@lists.freedesktop.org] on behalf of Lennart Poettering [lenn...@poettering.net] Sent: Friday, March 29, 2013 7:38 AM To: Frederic Crozat Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] A newbie question regarding ordering cycles On Thu, 28.03.13 13:47, Frederic Crozat (fcro...@suse.com) wrote: Le jeudi 28 mars 2013 à 12:22 +, Belal, Awais a écrit : Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: systemd[1]: Found ordering cycle on basic.target/start systemd[1]: Walked on cycle path to sockets.target/start systemd[1]: Walked on cycle path to dbus.socket/start systemd[1]: Walked on cycle path to sysinit.target/start systemd[1]: Walked on cycle path to run-postinsts.service/start systemd[1]: Walked on cycle path to basic.target/start systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start Based on experience, the problem usually lays in the .service listed in the cycle, in your case run-postinsts.service. It has probably incorrect (or no) LSB dependencies. Well, newer systemd versions do not allow early-boot SysV scripts anyway. There never was a standard way to do it. SysV scripts are only supported for normal services. systemd could be improved to not drop dbus.socket in its ordering cycle break algorithm (there were some discussions some time ago on IRC) but it hasn't happened yet. Well, I am not going to hardcode that dbus.socket is always the last one to be removed. There are certainly some changes possible (for example, kill the unit with the newest file modification date, as that is likely to be the most recently added that is borked), but tha's all black magic... I mean, this is generally not an end-user problem, more one that system integrators might run into, i.e. the folks who actually fiddle with early boot, and who write non-trivial unit files, so maybe trying to magically fix a broken situation isn't really worth it, but rather improve the debugging... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] A newbie question regarding ordering cycles
Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: systemd[1]: Found ordering cycle on basic.target/start systemd[1]: Walked on cycle path to sockets.target/start systemd[1]: Walked on cycle path to dbus.socket/start systemd[1]: Walked on cycle path to sysinit.target/start systemd[1]: Walked on cycle path to run-postinsts.service/start systemd[1]: Walked on cycle path to basic.target/start systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start Systemd is running in SysV compatibility mode. The odd thing here for me is once the system finishes booting I can see that dbus.service is up (through systemctl) but ofono and connman are never started although I can start them manually through systemctl. 1. How can such problems be disected and is there a way for knowing the dependency graph? 2. The ordering cycle was broken at dbus.socket/start, why aren't the other services tried out after that? BR, Awais ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
Le jeudi 28 mars 2013 à 12:22 +, Belal, Awais a écrit : Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: systemd[1]: Found ordering cycle on basic.target/start systemd[1]: Walked on cycle path to sockets.target/start systemd[1]: Walked on cycle path to dbus.socket/start systemd[1]: Walked on cycle path to sysinit.target/start systemd[1]: Walked on cycle path to run-postinsts.service/start systemd[1]: Walked on cycle path to basic.target/start systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start Based on experience, the problem usually lays in the .service listed in the cycle, in your case run-postinsts.service. It has probably incorrect (or no) LSB dependencies. systemd could be improved to not drop dbus.socket in its ordering cycle break algorithm (there were some discussions some time ago on IRC) but it hasn't happened yet. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
'Twas brillig, and Belal, Awais at 28/03/13 12:22 did gyre and gimble: Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: *systemd[1]: Found ordering cycle on basic.target/start* *systemd[1]: Walked on cycle path to sockets.target/start* *systemd[1]: Walked on cycle path to dbus.socket/start* *systemd[1]: Walked on cycle path to sysinit.target/start* *systemd[1]: Walked on cycle path to run-postinsts.service/start* *systemd[1]: Walked on cycle path to basic.target/start* *systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start* *systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start* Systemd is running in SysV compatibility mode. The odd thing here for me is once the system finishes booting I can see that dbus.service is up (through systemctl) but ofono and connman are never started although I can start them manually through systemctl. 1. How can such problems be disected and is there a way for knowing the dependency graph? 2. The ordering cycle was broken at dbus.socket/start, why aren't the other services tried out after that? BR, Awais As Frederic already said in his reply, I've found the most common case for ordering cycles is the lack of LSB headers in legacy sysvinit scripts. When there are no LSB headers systemd has to use the number in the symlink (the S??fooo bit) to determine the ordering. These orders frequently cause cycles. Another improvement to the cycle breaking logic could be to somehow boot out non-native units first (ideally non-LSB, followed by LSB, followed by native if sysvinit compatibility is compiled in). It's perhaps not overly clean to implement tho'. The cleanest solution is of course just to migrate away from sysvinit in any shape or form :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
On Thu, Mar 28, 2013 at 7:07 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Belal, Awais at 28/03/13 12:22 did gyre and gimble: Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: *systemd[1]: Found ordering cycle on basic.target/start* *systemd[1]: Walked on cycle path to sockets.target/start* *systemd[1]: Walked on cycle path to dbus.socket/start* *systemd[1]: Walked on cycle path to sysinit.target/start* *systemd[1]: Walked on cycle path to run-postinsts.service/start* *systemd[1]: Walked on cycle path to basic.target/start* *systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start* *systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start* Systemd is running in SysV compatibility mode. The odd thing here for me is once the system finishes booting I can see that dbus.service is up (through systemctl) but ofono and connman are never started although I can start them manually through systemctl. 1. How can such problems be disected and is there a way for knowing the dependency graph? 2. The ordering cycle was broken at dbus.socket/start, why aren't the other services tried out after that? BR, Awais As Frederic already said in his reply, I've found the most common case for ordering cycles is the lack of LSB headers in legacy sysvinit scripts. When there are no LSB headers systemd has to use the number in the symlink (the S??fooo bit) to determine the ordering. These orders frequently cause cycles. Another improvement to the cycle breaking logic could be to somehow boot out non-native units first (ideally non-LSB, followed by LSB, followed by native if sysvinit compatibility is compiled in). It's perhaps not overly clean to implement tho'. The cleanest solution is of course just to migrate away from sysvinit in any shape or form :) BTW, both ofono and connman projects are systemd-enabled and will install service files (check the configure flags) that should work properly with systemd. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
On Thu, 28.03.13 13:47, Frederic Crozat (fcro...@suse.com) wrote: Le jeudi 28 mars 2013 à 12:22 +, Belal, Awais a écrit : Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: systemd[1]: Found ordering cycle on basic.target/start systemd[1]: Walked on cycle path to sockets.target/start systemd[1]: Walked on cycle path to dbus.socket/start systemd[1]: Walked on cycle path to sysinit.target/start systemd[1]: Walked on cycle path to run-postinsts.service/start systemd[1]: Walked on cycle path to basic.target/start systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start Based on experience, the problem usually lays in the .service listed in the cycle, in your case run-postinsts.service. It has probably incorrect (or no) LSB dependencies. Well, newer systemd versions do not allow early-boot SysV scripts anyway. There never was a standard way to do it. SysV scripts are only supported for normal services. systemd could be improved to not drop dbus.socket in its ordering cycle break algorithm (there were some discussions some time ago on IRC) but it hasn't happened yet. Well, I am not going to hardcode that dbus.socket is always the last one to be removed. There are certainly some changes possible (for example, kill the unit with the newest file modification date, as that is likely to be the most recently added that is borked), but tha's all black magic... I mean, this is generally not an end-user problem, more one that system integrators might run into, i.e. the folks who actually fiddle with early boot, and who write non-trivial unit files, so maybe trying to magically fix a broken situation isn't really worth it, but rather improve the debugging... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
