[opensuse-factory] systemd dependency cycles
How do I find how what is causing these cycles? root@optiplex:~ # journalctl -b | grep delete Mai 15 13:00:17 optiplex systemd[1]: Job YaST2-Second-Stage.service/start deleted to break ordering cycle starting with wicked.service/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored_ro.socket/start deleted to break ordering cycle starting with sockets.target/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored.socket/start deleted to break ordering cycle starting with sockets.target/start Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, May 15, 2015 at 8:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
How do I find how what is causing these cycles?
root@optiplex:~ # journalctl -b | grep delete Mai 15 13:00:17 optiplex systemd[1]: Job YaST2-Second-Stage.service/start deleted to break ordering cycle starting with wicked.service/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored_ro.socket/start deleted to break ordering cycle starting with sockets.target/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored.socket/start deleted to break ordering cycle starting with sockets.target/start
There is currently no tool to inmediately analyze this, you have to a) read the unit files mentioned in the message (that indeed needs a bit a improvement) b) use systemd-analyze plot/dot to see a dependency graph. In the firsr case..The Yast-Second-stage service (that shouldn't even be enabled after the installation was complete, but for some reason is) Wants to start Before network.service (wicked) but AFTER xinetd which must be started after network.. The second case I do not know, as I do not have XEN installed. . -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Fri, 15 May 2015 11:44:26 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
On Fri, May 15, 2015 at 8:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
How do I find how what is causing these cycles?
root@optiplex:~ # journalctl -b | grep delete Mai 15 13:00:17 optiplex systemd[1]: Job YaST2-Second-Stage.service/start deleted to break ordering cycle starting with wicked.service/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored_ro.socket/start deleted to break ordering cycle starting with sockets.target/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored.socket/start deleted to break ordering cycle starting with sockets.target/start
There is currently no tool to inmediately analyze this, you have to
systemd should actually print the whole dependency chain before this message and also tell on which unit it hit the loop. Was it not the case here?
a) read the unit files mentioned in the message (that indeed needs a bit a improvement) b) use systemd-analyze plot/dot to see a dependency graph.
In the firsr case..The Yast-Second-stage service (that shouldn't even be enabled after the installation was complete, but for some reason is) Wants to start Before network.service (wicked) but AFTER xinetd which must be started after network..
The second case I do not know, as I do not have XEN installed. .
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 16.05.2015 um 07:59 schrieb Andrei Borzenkov:
В Fri, 15 May 2015 11:44:26 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
On Fri, May 15, 2015 at 8:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
How do I find how what is causing these cycles?
root@optiplex:~ # journalctl -b | grep delete Mai 15 13:00:17 optiplex systemd[1]: Job YaST2-Second-Stage.service/start deleted to break ordering cycle starting with wicked.service/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored_ro.socket/start deleted to break ordering cycle starting with sockets.target/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored.socket/start deleted to break ordering cycle starting with sockets.target/start
There is currently no tool to inmediately analyze this, you have to
systemd should actually print the whole dependency chain before this message and also tell on which unit it hit the loop. Was it not the case here?
You're right: Mai 14 07:23:14 linux-yb52 systemd-sysv-generator[678]: Overwriting existing symlink /run/systemd/generator.late/raw.service with real service Mai 14 07:23:14 linux-yb52 systemd[1]: Found dependency on YaST2-Second-Stage.service/start Mai 14 07:23:14 linux-yb52 systemd[1]: Found dependency on xinetd.service/start Mai 14 07:23:14 linux-yb52 systemd[1]: Breaking ordering cycle by deleting job network.target/start Mai 14 07:23:14 linux-yb52 systemd[1]: Job network.target/start deleted to break ordering cycle starting with xinetd.service/start Mai 14 07:23:14 linux-yb52 systemd[1]: Stopped Switch Root. Disabling YaST2-Second-Stage.service broke the cycle for me. Hendrik -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, May 16, Andrei Borzenkov wrote:
В Fri, 15 May 2015 11:44:26 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
On Fri, May 15, 2015 at 8:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
How do I find how what is causing these cycles?
root@optiplex:~ # journalctl -b | grep delete Mai 15 13:00:17 optiplex systemd[1]: Job YaST2-Second-Stage.service/start deleted to break ordering cycle starting with wicked.service/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored_ro.socket/start deleted to break ordering cycle starting with sockets.target/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored.socket/start deleted to break ordering cycle starting with sockets.target/start
There is currently no tool to inmediately analyze this, you have to
systemd should actually print the whole dependency chain before this message and also tell on which unit it hit the loop. Was it not the case here?
Yes, it shows this: root@optiplex:~ # journalctl -b | grep -B20 dele Mai 20 11:31:25 optiplex systemd-journal[158]: Journal stopped Mai 20 11:31:30 optiplex systemd-journal[477]: Runtime journal is using 8.0M (max allowed 394.3M, trying to leave 591.5M free of 3.8G available → current limit 394.3M). Mai 20 11:31:30 optiplex systemd-journal[477]: Permanent journal is using 412.7M (max allowed 2.9G, trying to leave 4.0G free of 20.2G available → current limit 2.9G). Mai 20 11:31:32 optiplex systemd-journal[477]: Time spent on flushing to /var is 1.786427s for 856 entries. Mai 20 11:31:32 optiplex systemd-journald[158]: Received SIGTERM from PID 1 (systemd). Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/rpmconfigcheck.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/after.local.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/local.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/raw.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/cifs.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/ebtables.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/xfs.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/esound.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/pppoe.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/halt.local.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/nfs.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/nfsserver.service with real service Mai 20 11:31:32 optiplex systemd[1]: Found dependency on NetworkManager-wait-online.service/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on NetworkManager.service/verify-active Mai 20 11:31:32 optiplex systemd[1]: Found dependency on YaST2-Second-Stage.service/start Mai 20 11:31:32 optiplex systemd[1]: Breaking ordering cycle by deleting job xinetd.service/start Mai 20 11:31:32 optiplex systemd[1]: Job xinetd.service/start deleted to break ordering cycle starting with YaST2-Second-Stage.service/start Mai 20 11:31:32 optiplex systemd[1]: Found ordering cycle on xenstored_ro.socket/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on proc-xen.mount/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on xen-dom0-modules.service/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on basic.target/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on sockets.target/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on xenstored_ro.socket/start Mai 20 11:31:32 optiplex systemd[1]: Breaking ordering cycle by deleting job proc-xen.mount/start Mai 20 11:31:32 optiplex systemd[1]: Job proc-xen.mount/start deleted to break ordering cycle starting with xenstored_ro.socket/start So what is wrong with xenstored_ro.socket? Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, May 20, 2015 at 12:40 PM, Olaf Hering <olaf@aepfle.de> wrote:
On Sat, May 16, Andrei Borzenkov wrote:
В Fri, 15 May 2015 11:44:26 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
On Fri, May 15, 2015 at 8:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
How do I find how what is causing these cycles?
root@optiplex:~ # journalctl -b | grep delete Mai 15 13:00:17 optiplex systemd[1]: Job YaST2-Second-Stage.service/start deleted to break ordering cycle starting with wicked.service/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored_ro.socket/start deleted to break ordering cycle starting with sockets.target/start Mai 15 13:00:17 optiplex systemd[1]: Job xenstored.socket/start deleted to break ordering cycle starting with sockets.target/start
There is currently no tool to inmediately analyze this, you have to
systemd should actually print the whole dependency chain before this message and also tell on which unit it hit the loop. Was it not the case here?
Yes, it shows this:
root@optiplex:~ # journalctl -b | grep -B20 dele Mai 20 11:31:25 optiplex systemd-journal[158]: Journal stopped Mai 20 11:31:30 optiplex systemd-journal[477]: Runtime journal is using 8.0M (max allowed 394.3M, trying to leave 591.5M free of 3.8G available → current limit 394.3M). Mai 20 11:31:30 optiplex systemd-journal[477]: Permanent journal is using 412.7M (max allowed 2.9G, trying to leave 4.0G free of 20.2G available → current limit 2.9G). Mai 20 11:31:32 optiplex systemd-journal[477]: Time spent on flushing to /var is 1.786427s for 856 entries. Mai 20 11:31:32 optiplex systemd-journald[158]: Received SIGTERM from PID 1 (systemd). Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/rpmconfigcheck.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/after.local.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/local.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/raw.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/cifs.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/ebtables.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/xfs.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/esound.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/pppoe.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/halt.local.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/nfs.service with real service Mai 20 11:31:32 optiplex systemd-sysv-generator[440]: Overwriting existing symlink /run/systemd/generator.late/nfsserver.service with real service Mai 20 11:31:32 optiplex systemd[1]: Found dependency on NetworkManager-wait-online.service/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on NetworkManager.service/verify-active Mai 20 11:31:32 optiplex systemd[1]: Found dependency on YaST2-Second-Stage.service/start Mai 20 11:31:32 optiplex systemd[1]: Breaking ordering cycle by deleting job xinetd.service/start Mai 20 11:31:32 optiplex systemd[1]: Job xinetd.service/start deleted to break ordering cycle starting with YaST2-Second-Stage.service/start Mai 20 11:31:32 optiplex systemd[1]: Found ordering cycle on xenstored_ro.socket/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on proc-xen.mount/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on xen-dom0-modules.service/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on basic.target/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on sockets.target/start Mai 20 11:31:32 optiplex systemd[1]: Found dependency on xenstored_ro.socket/start Mai 20 11:31:32 optiplex systemd[1]: Breaking ordering cycle by deleting job proc-xen.mount/start Mai 20 11:31:32 optiplex systemd[1]: Job proc-xen.mount/start deleted to break ordering cycle starting with xenstored_ro.socket/start
So what is wrong with xenstored_ro.socket?
I suspect that xenstored_ro.socket wants to be after /proc/xen which is by default after basic.target; but by default sockets are ordered before sockets.target which is before basic.target. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, May 20, Andrei Borzenkov wrote:
I suspect that xenstored_ro.socket wants to be after /proc/xen which is by default after basic.target; but by default sockets are ordered before sockets.target which is before basic.target.
How do I get ordering info about basic.target and sockets.target? Xen related output adjusted to the expected order: root@optiplex:~ # grep -Ei '^(\[|Want|Before|After|Req)' /usr/lib/systemd/system/*xen*.{service,mount,socket} /usr/lib/systemd/system/xen-dom0-modules.service:[Unit] /usr/lib/systemd/system/xen-dom0-modules.service:Before=proc-xen.mount /usr/lib/systemd/system/xen-dom0-modules.service:[Install] /usr/lib/systemd/system/xen-dom0-modules.service:WantedBy=multi-user.target /usr/lib/systemd/system/xen-dom0-modules.service:[Service] /usr/lib/systemd/system/proc-xen.mount:[Unit] /usr/lib/systemd/system/proc-xen.mount:[Mount] /usr/lib/systemd/system/var-lib-xenstored.mount:[Unit] /usr/lib/systemd/system/var-lib-xenstored.mount:Requires=proc-xen.mount /usr/lib/systemd/system/var-lib-xenstored.mount:After=proc-xen.mount /usr/lib/systemd/system/var-lib-xenstored.mount:[Mount] /usr/lib/systemd/system/xenstored.socket:[Unit] /usr/lib/systemd/system/xenstored.socket:Requires=proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored.socket:After=proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored.socket:[Socket] /usr/lib/systemd/system/xenstored.socket:[Install] /usr/lib/systemd/system/xenstored.socket:WantedBy=sockets.target /usr/lib/systemd/system/xenstored_ro.socket:[Unit] /usr/lib/systemd/system/xenstored_ro.socket:Requires=proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored_ro.socket:After=proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored_ro.socket:[Socket] /usr/lib/systemd/system/xenstored_ro.socket:[Install] /usr/lib/systemd/system/xenstored_ro.socket:WantedBy=sockets.target /usr/lib/systemd/system/xenstored.service:[Unit] /usr/lib/systemd/system/xenstored.service:Requires=xenstored_ro.socket xenstored.socket proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored.service:After=proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored.service:Before=libvirtd.service libvirt-guests.service /usr/lib/systemd/system/xenstored.service:[Service] /usr/lib/systemd/system/xenstored.service:[Install] /usr/lib/systemd/system/xenstored.service:WantedBy=multi-user.target /usr/lib/systemd/system/xen-init-dom0.service:[Unit] /usr/lib/systemd/system/xen-init-dom0.service:Requires=xenstored.service proc-xen.mount /usr/lib/systemd/system/xen-init-dom0.service:After=xenstored.service proc-xen.mount /usr/lib/systemd/system/xen-init-dom0.service:[Service] /usr/lib/systemd/system/xen-init-dom0.service:[Install] /usr/lib/systemd/system/xen-init-dom0.service:WantedBy=multi-user.target /usr/lib/systemd/system/xenconsoled.service:[Unit] /usr/lib/systemd/system/xenconsoled.service:Requires=proc-xen.mount xenstored.service /usr/lib/systemd/system/xenconsoled.service:After=proc-xen.mount xenstored.service /usr/lib/systemd/system/xenconsoled.service:[Service] /usr/lib/systemd/system/xenconsoled.service:[Install] /usr/lib/systemd/system/xenconsoled.service:WantedBy=multi-user.target /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service:[Unit] /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service:Requires=proc-xen.mount xenstored.service /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service:After=proc-xen.mount xenstored.service xenconsoled.service /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service:Before=xendomains.service libvirtd.service libvirt-guests.service /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service:[Service] /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service:[Install] /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service:WantedBy=multi-user.target /usr/lib/systemd/system/xencommons.service:[Unit] /usr/lib/systemd/system/xencommons.service:Requires=xen-dom0-modules.service /usr/lib/systemd/system/xencommons.service:After=xen-dom0-modules.service /usr/lib/systemd/system/xencommons.service:Requires=proc-xen.mount /usr/lib/systemd/system/xencommons.service:After=proc-xen.mount /usr/lib/systemd/system/xencommons.service:Requires=xenstored.service /usr/lib/systemd/system/xencommons.service:After=xenstored.service /usr/lib/systemd/system/xencommons.service:Requires=xenconsoled.service /usr/lib/systemd/system/xencommons.service:After=xenconsoled.service /usr/lib/systemd/system/xencommons.service:Requires=xen-init-dom0.service /usr/lib/systemd/system/xencommons.service:After=xen-init-dom0.service /usr/lib/systemd/system/xencommons.service:Requires=xen-qemu-dom0-disk-backend.service /usr/lib/systemd/system/xencommons.service:After=xen-qemu-dom0-disk-backend.service /usr/lib/systemd/system/xencommons.service:After=network-online.target /usr/lib/systemd/system/xencommons.service:After=remote-fs.target /usr/lib/systemd/system/xencommons.service:Before=xendomains.service libvirtd.service /usr/lib/systemd/system/xencommons.service:[Service] /usr/lib/systemd/system/xencommons.service:[Install] /usr/lib/systemd/system/xencommons.service:WantedBy=multi-user.target /usr/lib/systemd/system/xendomains.service:[Unit] /usr/lib/systemd/system/xendomains.service:Requires=proc-xen.mount xenstored.service /usr/lib/systemd/system/xendomains.service:After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service /usr/lib/systemd/system/xendomains.service:After=network-online.target /usr/lib/systemd/system/xendomains.service:After=remote-fs.target /usr/lib/systemd/system/xendomains.service:[Service] /usr/lib/systemd/system/xendomains.service:[Install] /usr/lib/systemd/system/xendomains.service:WantedBy=multi-user.target /usr/lib/systemd/system/xen-watchdog.service:[Unit] /usr/lib/systemd/system/xen-watchdog.service:Requires=proc-xen.mount /usr/lib/systemd/system/xen-watchdog.service:After=proc-xen.mount xendomains.service /usr/lib/systemd/system/xen-watchdog.service:[Service] /usr/lib/systemd/system/xen-watchdog.service:[Install] /usr/lib/systemd/system/xen-watchdog.service:WantedBy=multi-user.target Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, May 20, 2015 at 2:00 PM, Olaf Hering <olaf@aepfle.de> wrote:
On Wed, May 20, Andrei Borzenkov wrote:
I suspect that xenstored_ro.socket wants to be after /proc/xen which is by default after basic.target; but by default sockets are ordered before sockets.target which is before basic.target.
How do I get ordering info about basic.target and sockets.target?
In systemd documentaition? http://www.freedesktop.org/software/systemd/man/systemd.special.html basic.target A special target unit covering basic boot-up. systemd automatically adds dependencies of the types Requires= and After= for this target unit to all services (except for those with DefaultDependencies=no). Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic initialization necessary for general purpose daemons.
Xen related output adjusted to the expected order:
root@optiplex:~ # grep -Ei '^(\[|Want|Before|After|Req)' /usr/lib/systemd/system/*xen*.{service,mount,socket}
/usr/lib/systemd/system/xen-dom0-modules.service:[Unit] /usr/lib/systemd/system/xen-dom0-modules.service:Before=proc-xen.mount
This orders /proc/xen after xen-dom0-modules.service. Be default every service unit is ordered after basic target: http://www.freedesktop.org/software/systemd/man/systemd.service.html Unless DefaultDependencies= is set to false, service units will implicitly have dependencies of type Requires= and After= on basic.target as well as dependencies of type Conflicts= and Before= on shutdown.target. These ensure that normal service units pull in basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early boot or late system shutdown should disable this option.
/usr/lib/systemd/system/xenstored_ro.socket:[Unit] /usr/lib/systemd/system/xenstored_ro.socket:Requires=proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored_ro.socket:After=proc-xen.mount var-lib-xenstored.mount /usr/lib/systemd/system/xenstored_ro.socket:[Socket] /usr/lib/systemd/system/xenstored_ro.socket:[Install] /usr/lib/systemd/system/xenstored_ro.socket:WantedBy=sockets.target
This makes xenstored_ro.socket ordered before sockets.target. Unless DefaultDependencies= is set to false, target units will implicitly complement all configured dependencies of type Wants=, Requires=, RequiresOverridable= with dependencies of type After= if the units in question also have DefaultDependencies=true. and sockets.target comes before basic.target. Just look at http://man7.org/linux/man-pages/man7/bootup.7.html. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, May 15, Cristian Rodríguez wrote:
In the firsr case..The Yast-Second-stage service (that shouldn't even be enabled after the installation was complete, but for some reason is) Wants to start Before network.service (wicked) but AFTER xinetd which must be started after network..
http://bugzilla.suse.com/show_bug.cgi?id=931643
The second case I do not know, as I do not have XEN installed.
Not sure, but appearently I had an old and enabled .service file around for bnc#927750. My first version had a different name than the one that went into xen-tools.rpm. Maybe it was still enabled. Now I removed it and xen starts. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Cristian Rodríguez -
Hendrik Woltersdorf -
Olaf Hering