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

Benoit benoitne at gmail.com
Thu Feb 4 22:10:32 UTC 2016

Apparently no,

What are the rhel/Fedora scripts just for me to double check?

On 04/02/16 20:39, Flavio Leitner wrote:
> 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.

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

More information about the discuss mailing list