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
On 04/02/16 12:49, Flavio Leitner wrote:
On Wed, 3 Feb 2016 22:01:46 -0500
Mark Mielke <mark.mie...@gmail.com> wrote:
On Wed, Feb 3, 2016 at 9:22 PM, Flavio Leitner <f...@redhat.com> wrote:
On Wed, 3 Feb 2016 20:15:11 -0500
Mark Mielke <mark.mie...@gmail.com> wrote:
On Wed, Feb 3, 2016 at 3:09 PM, Flavio Leitner <f...@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.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
