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

Aaron Conole aconole at redhat.com
Wed Jul 18 15:24:43 UTC 2018

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.

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).


More information about the dev mailing list