[ovs-discuss] systemd ovs-vswitchd starts too early

Thu Feb 4 20:39:55 UTC 2016

On Thu, 4 Feb 2016 17:23:44 +0000
Benoit <benoitne at gmail.com> wrote:

> Hi,
> 
> Just to say that I got the same issue on ArchLinux (Parabola to be 
> accurate) which use SystemD as well.
> I wrote something probably one month ago here but not a lot of replies

Does ArchLinux use rhel/Fedora systemd initialization scripts?

--
fbl

> On 04/02/16 12:49, Flavio Leitner wrote:
> > 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 start after.
> >
> > 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. 