Hi Ilya, Thanks for the feedback.
I addressed this in v4: https://mail.openvswitch.org/pipermail/ovs-dev/2026-July/434360.html The tmpfiles-based behavior is now opt-in via --enable-tmpfiles-log-ownership, which is disabled by default. In the default configuration, ovn-ctl and ovn-lib retain the existing recursive log-directory chown behavior, so deployments that do not use systemd services or systemd-tmpfiles are unaffected. Debian and Fedora explicitly enable the option in their packaging. Best regards, Zhang Hua On Mon, Jul 20, 2026 at 8:04 PM Ilya Maximets <[email protected]> wrote: > On 7/13/26 6:30 AM, Zhang Hua via dev wrote: > > ovn-ctl and ovn-lib currently chown the OVN log directory recursively > > when services start. That can undo ownership set by distribution > > tooling such as tmpfiles.d and logrotate. In particular, Debian and > > Ubuntu need ovn-controller.log to remain root:adm so rsyslog can read > > it, but a later OVN service restart may change it back to the OVN > > daemon user/group. > > > > Add OVN tmpfiles.d and sysusers.d templates for the log directory, > > ovn-controller.log and the configured log owner/group. The log user, > > log group, tmpfiles.d installation directory and sysusers.d installation > > directory are configurable so downstream packages can choose their local > > policy. Debian configures the log owner as root:adm and installs the > > generated sysusers.d file for the adm group. Fedora/RHEL keeps > > openvswitch:openvswitch for log ownership, but leaves the openvswitch > > user to the Open vSwitch package's sysusers.d configuration. > > > > Stop recursively changing the OVN log directory ownership from ovn-ctl > > and ovn-lib at service startup. Runtime, database and configuration > > paths are still chowned according to --ovn-user, preserving the existing > > privilege-drop behavior for non-log state. > > > > Reported-at: https://github.com/ovn-org/ovn/issues/310 > > Signed-off-by: Zhang Hua <[email protected]> > > --- > > [...] > > > diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl > > index 3b62ca9b7..58effd5e5 100755 > > --- a/utilities/ovn-ctl > > +++ b/utilities/ovn-ctl > > @@ -276,9 +276,8 @@ $cluster_remote_port > > upgrade_db "$file" "$schema" > > fi > > > > - # Set the owner of the ovn_dbdir (with -R option) to OVN_USER if > set. > > - # This is required because the ovndbs are created with root > permission > > - # if not present when create_cluster/upgrade_db is called. > > + # Database files may be created as root before ovsdb-server drops > > + # privileges, so keep ownership aligned with OVN_USER when > configured. > > INSTALL_USER="$(id -un)" > > INSTALL_GROUP="$(id -gn)" > > [ "$OVN_USER" != "" ] && INSTALL_USER="${OVN_USER%:*}" > > @@ -286,7 +285,6 @@ $cluster_remote_port > > > > chown -R $INSTALL_USER:$INSTALL_GROUP $ovn_dbdir > > chown -R $INSTALL_USER:$INSTALL_GROUP $OVN_RUNDIR > > - chown -R $INSTALL_USER:$INSTALL_GROUP $ovn_logdir > > chown -R $INSTALL_USER:$INSTALL_GROUP $ovn_etcdir > > > > set ovsdb-server > > diff --git a/utilities/ovn-lib.in b/utilities/ovn-lib.in > > index 5a0766816..0b19149da 100644 > > --- a/utilities/ovn-lib.in > > +++ b/utilities/ovn-lib.in > > @@ -133,7 +133,6 @@ start_ovn_daemon () { > > set "$@" --detach > > test X"$MONITOR" = Xno || set "$@" --monitor > > > > - chown -R $INSTALL_USER:$INSTALL_GROUP $ovn_logdir > > chown -R $INSTALL_USER:$INSTALL_GROUP $ovn_rundir > > > > start_wrapped_daemon "$wrapper" $daemon "$priority" "$@" > Not a full review, but it seems like removing this code from ovn-ctl > and ovn-lib will break setups that are not using systemd services for > managing OVN. The new behavior may need to be opt-in. > > Best regards, Ilya Maximets. > -- Best Regards Zhang Hua(张华） Software Engineer | Canonical IRC: zhhuabj We are hiring <https://canonical.com/careers?utm_source=signature&utm_medium=email> | Life at Canonical <https://www.linkedin.com/company/canonical/life/> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
