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