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 <benoi...@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.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
