Bugzilla – Bug 809821
open-iscsi is causing a dependency cycle in systemd
Last modified: 2013-05-29 16:58:17 UTC
From witin a xterm: /home/werner> sudo -i speedy:~ # systemctl status dbus.service dbus.service - D-Bus System Message Bus Loaded: loaded (/usr/lib/systemd/system/dbus.service; static) Active: inactive (dead) CGroup: name=systemd:/system/dbus.service speedy:~ # systemctl status polkit.service polkit.service - Authorization Manager Loaded: loaded (/usr/lib/systemd/system/polkit.service; enabled) Active: inactive (dead) Docs: man:polkit(8) CGroup: name=systemd:/system/polkit.service speedy:~ # ... IMHO broken as several services are not available. Beside this the systemd seems to very slow in comparision with the former sysvinit (11.4).
Just added Requires=dbus.service polkit.service before After=dbus.service polkit.service in /usr/lib/systemd/system/graphical.target and now it works. It seems that Wants= is not sufficient to trigger the start but only a suggestion.
Please attach dmesg output after booting with "systemd.log_level=debug systemd.log_target=kmsg" and without your changes to graphical.target. starting dbus.service is not needed, it will be auto-pulled by dbus.socket. I'm pretty sure you have something which is evincting dbus.service from the dependency graph (here is why I need the debug output). Upstream is working on improving the eviction algorithm to prevent essential services like dbus to be remove from the dependency chain.
OK ... this or next evening as the workstation for my familiy is located at home. Beside this I've seen a lot of messages on the logs of breaking cycles from systemd. Maybe a dependency check could be done for every service we have around to make sure the cycles do not happen. IME this had solved a lot of trouble at boot time but caused trouble to explain the packagers their own boot scripts. I guess this also applies for systemd ;)
(In reply to comment #3) > Beside this I've seen a lot of messages on the logs of breaking cycles from > systemd. Maybe a dependency check could be done for every service we have > around to make sure the cycles do not happen. IME this had solved a lot of > trouble at boot time but caused trouble to explain the packagers their own boot > scripts. I guess this also applies for systemd ;) We could try to install ALL available LSB initscripts + systemd .service, get them "enabled" and see how much cycle there are. Please note that boot.* initscripts (run before $local_fs) is going away in upcoming systemd (for Factory ie 13.1), we should either write a generator to handle those or just port them to .service files. But that's another story :)
...(In reply to comment #2) OK ... /home/werner> ps aux | grep -E 'polkit|dbus' werner 3885 0.0 0.0 14204 832 ? S 17:55 0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/gpg-agent --sh --daemon --write-env-file /home/werner/.gnupg/agent.info /usr/bin/ssh-agent /home/werner/.xinitrc werner 3927 0.0 0.0 14196 828 ? S 17:55 0:00 dbus-launch --sh-syntax --exit-with-session fvwm2 werner 3928 0.0 0.0 22164 1064 ? Ss 17:55 0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session werner 4163 0.0 0.0 7052 864 pts/0 S+ 17:58 0:00 grep -E polkit|dbus /home/werner> systemctl list-units Failed to get D-Bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory /home/werner> sudo -i speedy:~ # systemctl list-units > ~werner/serv.lists ... now I'll start dbus as well as polkit (btw: with dbus and polkit systemd is much faster) speedy:~ # systemctl start dbus.service speedy:~ # systemctl start polkit.service speedy:~ # logout /home/werner> dmesg > dmesg.list
Created attachment 530232 [details] ~werner/serv.lists
Created attachment 530233 [details] ~werner/dmesg.list
Btw: Why is a not not existing YP/NIS a fatal error?
[ 3.455299] systemd[1]: Found ordering cycle on basic.target/start [ 3.455301] systemd[1]: Walked on cycle path to sockets.target/start [ 3.455303] systemd[1]: Walked on cycle path to dbus.socket/start [ 3.455305] systemd[1]: Walked on cycle path to sysinit.target/start [ 3.455307] systemd[1]: Walked on cycle path to open-iscsi.service/start [ 3.455308] systemd[1]: Walked on cycle path to basic.target/start [ 3.455310] systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start [ 3.455337] systemd[1]: Deleting job avahi-daemon.service/start as dependency of job dbus.socket/start [ 3.455340] systemd[1]: Deleting job systemd-logind.service/start as dependency of job dbus.socket/start [ 3.455342] systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start [ 3.455345] systemd[1]: Deleting job polkit.service/start as dependency of job dbus.socket/start [ 3.455349] systemd[1]: Found ordering cycle on basic.target/start [ 3.455351] systemd[1]: Walked on cycle path to sendmail-client.path/start [ 3.455353] systemd[1]: Walked on cycle path to sysinit.target/start [ 3.455354] systemd[1]: Walked on cycle path to open-iscsi.service/start [ 3.455356] systemd[1]: Walked on cycle path to basic.target/start [ 3.455358] systemd[1]: Breaking ordering cycle by deleting job sendmail-client.path/start [ 3.455377] systemd[1]: Found ordering cycle on basic.target/start [ 3.455379] systemd[1]: Walked on cycle path to sysinit.target/start [ 3.455381] systemd[1]: Walked on cycle path to open-iscsi.service/start [ 3.455383] systemd[1]: Walked on cycle path to basic.target/start [ 3.455384] systemd[1]: Breaking ordering cycle by deleting job open-iscsi.service/start [ 3.455422] systemd[1]: Fixing conflicting jobs by deleting job graphical.target/stop Could you try to uninstall open-iscsi ? (In reply to comment #8) > Btw: Why is a not not existing YP/NIS a fatal error? you should still be able to login with local user (it should timeout after a while).
The missing YP/NIS does not cause any timeout ... only the read message is not required ... IMHO a yellow with SKIPED isa just enough ;) The only question is if plymouth only knows exit status 0 and 1
(In reply to comment #9) > Could you try to uninstall open-iscsi ? Just removed my entries from graphical.target and rebooted .. perfect job. All here polkit.service, dbus-service, and systemd-logind.serice with its agetties on demand. Thanks a lot! Btw: How has written this open-iscsi.service? I'm pretty sure the original insserv would detect such loops ;)
*** Bug 809807 has been marked as a duplicate of this bug. ***
*** Bug 809811 has been marked as a duplicate of this bug. ***
@Frankie: Even if systemd is the bearer of bad tidings, the bug its self caused by open-iscsi due wrong dependcies. @Hannes: Please could have look in your package? It break a lot of openSUSE 12.3 installations and will break the future SLES12
This seems to be a duplicate of bug#630434. Please install the latest update for open-iscsi. (Or remove the open-iscsi rpm if you don't need iSCSI). But you are correct, the systemd integration does need some work.
Lee, we talked about this at LSF.
I will check it out.
I'm at a little bit of a loss here. The open-iscsi service on openSUSE 12.3 is iscsid.service. There is no open-iscsi.service that I know of. What version of open-iscsi was causing this dependency? I have: linux-yxto:/home/lduncan # uname -a Linux linux-yxto 3.7.10-1.1-desktop #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21) x86_64 x86_64 x86_64 GNU/Linux linux-yxto:/home/lduncan # rpm -q open-iscsi open-iscsi-2.0.870-47.1.1.x86_64 linux-yxto:/home/lduncan # cat /etc/SuSE-release openSUSE 12.3 (x86_64) VERSION = 12.3 CODENAME = Dartmouth
(In reply to comment #18) IMHO this was due to an sysvinit based init file /etc/init.d/open-iscsi. Maybe this was a left over from update process where zypper had not updated the open-iscsi package from 11.4 to 12.3. Beside this: Why is the version of open-iscsi 2.0.870 on openSUSE 12.3 whereas the version on SLES11-SP3 is 2.0.873 ... AFAIK the next SLES12 will be based on openSUSE Factory. Also the systemd unit files seems to be missed as there are only sysvinit based init files.
Werner: I think you guess is correct -- the open-iscsi.service must have come from an init file name /etc/init.d/open-iscsi, which should not be there. I believe this bug can be closed ... As for your second question, the open-iscsi on openSUSE needs to be updated. If you'd like, please file a bug on that second issue and set me as the responsible engineer ("Assigned To").
Closing this bug resolved, since it seems to have been some sort of upgrade or configuration problem. A separate bug on upgrading open-iscsi in openSUSE has been created and is being worked on.