Guru Shetty <g...@ovn.org> writes: > On Fri, 3 May 2019 at 11:36, Aaron Conole <acon...@redhat.com> wrote: > > Gurucharan Shetty <g...@ovn.org> writes: > > > Currently we have rhel/openvswitch.spec.in that provides > > sysv scripts. The fedora package provides systemd scripts. > > If one upgrades openvswitch package from sysv to systemd, > > you will end up in a situation where old OVS daemons are > > running, but systemd does not know about it. One "restart" > > is needed for systemd to see the old daemons. Another "restart" > > or "force-reload-kmod" is needed to actually use the new > > daemons. > > Is this true? I thought the restart would actually run the restart > action and that would spawn new instances of the daemons. It seems like > a strange behavior. > > systemd openvswitch scripts when installed, hasn't been started yet in its > history. So they do not know that > any daemon has been started. So a "stop" will not stop old daemons.
The restart does, though - right? IIRC, the ExecStop= will be called and terminate the old daemons first. I just want to make sure that it's documented if process will be terminated (via the ExecStop= action) so that any audit log can be explained. As it is written, the behavior isn't clear whether the untracked daemons are stopped. > > This commit, just takes care of the first restart. The "real" > > restart/force-reload-kmod will still have to be done outside > > the package installation. > > > > Signed-off-by: Gurucharan Shetty <g...@ovn.org> > > --- > > I'm still not clear on the reasoning to only do the 'restart' on > upgrade from the sysv style. If we're going through the trouble to > auto-enable it seems confusing that the service gets enabled but not > started, but only sometimes. Maybe it's best that if this autoenable > flag is set, the daemons are also spawned. > > The "restart" being done here is only to make systemd aware of old daemons. > The old rhel rpm did not > restart/force-reload-kmod old daemons either. > So this just brings fedora rpm to parity with rhel rpm. There is pre-built > infrastructure that handle restart vs > force-reload-kmod for rhel based openvswitch rpms. If we respawn daemons, it > will cause them to get > confused. I think the idea is to bring RHEL to match Fedora, though. Not the other way around. Fedora is upstream for RHEL. I still don't understand why on upgrade we will always enable ovs (even if the user didn't want it), but not also always start it. After all, a system reboot will cause it to start. Does it make sense to skip the reboot step and just allow ovs to start? > > rhel/openvswitch-fedora.spec.in | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/rhel/openvswitch-fedora.spec.in > b/rhel/openvswitch-fedora.spec.in > > index e8165f9..d41d11c 100644 > > --- a/rhel/openvswitch-fedora.spec.in > > +++ b/rhel/openvswitch-fedora.spec.in > > @@ -364,6 +364,12 @@ getent passwd openvswitch >/dev/null || \ > > usermod -a -G hugetlbfs openvswitch > > %endif > > %endif > > + > > +%if %{with autoenable} > > + if [ -x "/etc/init.d/openvswitch" ]; then > > + touch %{_tmppath}/ovs-upgrade-from-sysv > > + fi > > +%endif > > exit 0 > > > > %post > > @@ -397,6 +403,14 @@ fi > > %if %{with autoenable} > > systemctl daemon-reload > > systemctl enable openvswitch > > + # Handle upgrades to this package from the OVS repo's rhel packages. > > + # One "restart" is needed for newer systemd files to see the old > running > > + # daemons. Another "restart" (outside the package postinst script) is > > + # needed to actually run new daemons. > > + if [ -e "%{_tmppath}/ovs-upgrade-from-sysv" ]; then > > + systemctl restart openvswitch > > + rm "%{_tmppath}/ovs-upgrade-from-sysv" > > + fi > > %endif > > > > %post selinux-policy _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev