[ovs-dev] [PATCH] utilities: Run ovsdb-server pre-startup DB steps as root

Flavio Leitner fbl at redhat.com
Wed Jul 18 20:28:48 UTC 2018

On Wed, Jul 18, 2018 at 11:24:43AM -0400, Aaron Conole wrote:
> Markos Chandras <mchandras at suse.de> writes:
> > When ovsdb-server is starting, it performs some DB steps such as
> > creating and upgrading the OvS DB. When we are running as
> > 'non-root' user, the 'runuser' tool is used to manage the privileges.
> > However, when this happens during systemd boot, we observe the following
> > errors in journald:
> >
> > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Failed to add PIDs to scope's control group: No such process
> > Jun 21 07:32:57 virt systemd[1]: Failed to start Session c1 of user openvswitch.
> > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Unit entered failed state.
> >
> > According to the analysis performed on openSUSE bugzilla[1], it seems
> > that ovsdb-server.service creates (via the call to runuser) a user
> > session and therefore call pam_systemd which in its turn tries to start
> > a systemd user instance: "user at 474.service". However "user at 474.service"
> > is supposed to be started after systemd-user-sessions.service which is
> > supposed to be started after network.target. Additionally,
> > ovsdb-server.service uses Before=network.target hence the deadlock.
> >
> > We can workaround this by switching to 'root' user when we are
> > performing this pre-startup steps and fixup the DB permissions before
> > we start the actual ovsdb-server daemon.
> >
> > [1]: https://bugzilla.suse.com/show_bug.cgi?id=1098630
> > Cc: Aaron Conole <aconole at redhat.com>
> > Signed-off-by: Markos Chandras <mchandras at suse.de>
> > ---
> > Probably not the cleanest option so I am open to suggestions :)
> I think there's actually a race condition here.  Most likely,
> ovsdb-server doesn't need to be started before network.service.

Unfortunately it does because network.service will ifup OVS bridges
and ports and then we need ovsdb already running.


> Looking at the bug, I think we can unroll some of the dependencies that
> each unit file has and get a cleaner systemd dependency chain, and
> preserve the existing user downgrade.
> I will install an OpenSUSE VM and work on it.  Strange that we don't see
> this on the RHEL side.  I'll also try to reproduce that.
> Thanks for pointing the issue out (and thanks to David and Franck on
> your side).
> -Aaron

More information about the dev mailing list