[systemd-devel] network/openvswitch dependency loop/deadlock

Thomas Graf tgraf at redhat.com
Tue Feb 12 05:07:45 PST 2013

On 02/07/2013 04:55 PM, Ian Pilcher wrote:
> On 02/07/2013 06:13 AM, Colin Guthrie wrote:
>> Also re the initscripts tweaks and the if statement proposed in the bug,
>> there is a SYSTEMCTL_IGNORE_DEPENDENCIES=1 env var you can export that
>> will make "service openvswitch start" pass the --ignore-dependencies
>> argument if it redirects to systemctl. That's likely cleaner than the if
>> [ -x /usr/bin/systemctl ] check. Obviously as this is arguably not the
>> right fix anyway, it's perhaps a moot point.
> Cool.
> So given that it is in fact "After=... network.target" (in
> openvswitch.service) that is causing the problem, do you see a better
> Is there any chance that this would work?
>    After=syslog.target
>    Requires=network.target
> (While not breaking the use case in comment #34 of the bug.)
> I'm very unclear on what Requires=network.target would actually mean.

The case of Open vSwitch is a bit special because there is a chicken
egg problem.

OVS bridges and ports are configured using the ovs-vsctl utility. It
requires the OVS daemons to be running. So naturally we want to start
the openvswitch unit (if it is not running yet) before we ifup any
OVS type interfaces.

We also want the openvswitch unit to be started after network on boot
because an OVS bridge may be using a controller on the network that
depends on network connectivity.

So what we did is introduce a new ifcfg key that can be used to define
the interface dependencies of a bridge. Let's say ovsbr0 is configured
to use a controller that is behind interface em1. So before bringing
up ovsbr0 we want to bring up em1 and after that we want to start the
openvswitch unit and then configure the bridge.

So it seems what we need is a way to tell systemd to disregard the
network dependency if we are starting the openvswitch unit from within
ifup. Something like --ignore-dependency=network.target because we
still want it to depend on syslog.target obviously.

I guess we could also be providing a separate units files:

What is cleaner from a systemd perspective?

More information about the systemd-devel mailing list