[systemd-devel] network/openvswitch dependency loop/deadlock
arequipeno at gmail.com
Wed Feb 6 14:27:57 PST 2013
Recently, Fedora shipped an update which starts the Open vSwitch service
on demand -- whenever an Open vSwitch bridge or port is "ifup'ed". In
theory, I should now be able to simply write traditional ifcfg-* files
for all of my interfaces and use the "network" service to start them.
Unfortunately, my interfaces are not starting properly. I believe that
the sequence of events is as follows:
* systemd starts the network service (/etc/rc.d/init.d/network)
* The network tries to start an interface (ifup eth0)
* ifup reads "TYPE=ovs" from ifcfg-eth0 and executes ifup-ovs
* ifup-ovs sees that the Open vSwitch daemon is not running
(/var/lock/subsys/openvswitch does not exist) and executes "service
* /usr/sbin/service executes "systemctl start openvswitch.service"
* systemd sees "Before=... network.target" in openvswitch.service and
waits for the network service to complete -- which will never happen,
because the network service is waiting for the openvswitch servicr to
At this point, everything grinds to a halt. The "systemctl start
openvswitch service" process hangs, and the network service sits there
waiting for it to complete.
After 5 minutes, systemd kills the network service. Since the network
service is no longer running, systemd considers that the network.target
has been reached and starts the Open vSwitch daemon.
Various bits of information about my system are posted here:
All of this is background to my question -- is this dependency loop/
deadlock the expected behavior in this case?
Assuming that the answer is yes, what is the best way to work around
* Removing network.target from the Before=... line in
openvswitch.service is not an option. See comment #1 of that bug.
* Changing the network startup script (ifup-ovs) to use "systemctl
--ignore-dependencies start openvswitch.service" appears to work, but
the man page discourages its use for anything but debugging.
It would be very nice to not have to create another unit file just to
ignore this single dependency in this single circumstance.
Ian Pilcher arequipeno at gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
More information about the systemd-devel