[ovs-discuss] systemd ovs-vswitchd starts too early
fbl at redhat.com
Thu Feb 4 12:49:59 UTC 2016
On Wed, 3 Feb 2016 22:01:46 -0500
Mark Mielke <mark.mielke at gmail.com> wrote:
> On Wed, Feb 3, 2016 at 9:22 PM, Flavio Leitner <fbl at redhat.com> wrote:
> > On Wed, 3 Feb 2016 20:15:11 -0500
> > Mark Mielke <mark.mielke at gmail.com> wrote:
> >> On Wed, Feb 3, 2016 at 3:09 PM, Flavio Leitner <fbl at redhat.com>
> >> wrote:
> >> > OK, the issue seems to be the fact that network.service is a sysV
> >> > script which gets translated to systemd service but it doesn't
> >> > have any relation to network.target.
> >> >
> >> > Could you please try this patch? It will require
> >> > openvswitch.service to run after network.service which was the
> >> > initial intention.
> >> >
> >> > diff --git a/rhel/usr_lib_systemd_system_openvswitch.service
> >> > b/rhel/usr_lib_systemd_system_openvswitch.service index
> >> > f0bc16f..a391dfe 100644 ---
> >> > a/rhel/usr_lib_systemd_system_openvswitch.service +++
> >> > b/rhel/usr_lib_systemd_system_openvswitch.service @@ -1,6 +1,6 @@
> >> > [Unit]
> >> > Description=Open vSwitch
> >> > -After=syslog.target network.target openvswitch-nonetwork.service
> >> > +After=syslog.target network.target openvswitch-nonetwork.service
> >> > network.service Requires=openvswitch-nonetwork.service
> >> >
> >> > [Service]
> >> I updated the /usr/lib/systemd/system/openvswitch.service in place,
> >> and it appears to have no effect. The network.service may be a SysV
> >> script, but it does define:
> >> ### BEGIN INIT INFO
> >> # Provides: $network
> >> ...
> >> ### END INIT INFO
> >> I believe this is a hint to systemd to do the right thing, and that
> >> this helps it align with network.target which has:
> >> After=network-pre.target
> >> I think this has no effect, because although it causes
> >> openvswitch.service to be delayed until after network.service
> >> (which is actually less restricted than after network.target?), it
> >> does not prevent openvswitch-nonetwork.service from starting too
> >> early. The only constraint on openvswitch-nonetwork.service is:
> >> After=syslog.target
> >> As soon as syslog.target is achieved, openvswitch-nonetwork.service
> >> may start. With a fast enough machine, and a slow enough
> >> network.service-initiated physical interface initiation,
> >> openvswitch-nonetwork.service will start before the physical
> >> interfaces are ready, which results in the problems we are
> >> discussion.
> >> If this is a correct summary of the situation, then it makes me
> >> think that that openvswitch-nonetwork.service isn't really working
> >> as intended, at least not with network.service? Or, it only works
> >> as intended if your use case does not include openvswitch managing
> >> your physical network interfaces?
> > It should _not_ prevent openvswitch-nonetwork.service to start.
> > Actually, that is the reason for its name. :-)
> Yep, understood. However, it is contradictory, because if the
> openvswitch configuration references physical network interfaces, then
> actually network is required.
> > The openvswitch-nonetwork is meant to be started by demand. So,
> > either openvswitch.service will start it at appropriate time or
> > ifup-ovs when configuring an OVS port because 'network.service' is
> > running and processing all ifcfg- files.
> I think the conclusion here is that openvswitch.service cannot start
> it at the appropriate time. At least not with the current options on
> the table. But, see below for what I mean...
> > We need to split the issues: One is that enabling
> > openvswitch.service causes it to run too soon. I think the
> > proposed patch should resolve that (check journalctl -xe).
> The proposed patch doesn't seem to change anything. I checked
> /var/log/messages and journalctl -xe. It has zero impact on the order
> of the boot up. openvswitch-nonetwork.service still starts too soon,
> before the physical interfaces have been probed and recognized. In
> both cases, systemd has determined that openvswitch-nonetwork.service
> is a dependency, and it starts it as soon as syslog.target is reached
> (which is the constraint that openvswitch-nonetwork.service defines).
> Adding "After=network.service" to openvswitch.service does not affect
> when openvswitch-nonetwork.service starts as "After=network.target" is
> already more constraining than "After=network.service"...
It seems you're mixing the issues.
openvswitch-nonetwork.service should not start by itself because it
should not be enabled. It is considered internal to OVS initialization.
Now there are two ways to start that service. The important one is when
'network.service' is _running_ and processing ifcfg files. That is a
loop processing ifcfgs one by one and when it finds the first ifcfg for
an OVS port, it will start openvswitch-nonetwork.service because it
needs the service at that point. We didn't start earlier and we can't
So, it can't be after network.target and can't be after network.service.
However, if you have interfaces added from previous boot remaining in
the OVS DB, OVS will keep them when you start OVS daemons. So, you will
see them on the OVS _before_ they are actually available in the system
or brought up by network.service.
The OVS initialization just fires up OVS daemons. It doesn't configure
any ports or bridges because historically on Fedora that is what the
network.service does, for each ifcfg- file available.
Regarding to the second issue that we need to clean stale bonding ports
from the DB to start from scratch I can provide a patch, but let's see
about the first issue to avoid confusions and misunderstandings.
More information about the discuss