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

Benoit benoitne at gmail.com
Thu Feb 4 17:23:44 UTC 2016


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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160204/f30534b1/attachment-0002.html>

More information about the discuss mailing list