ctdb nfs rquotad: inconsistency between startup and checks

Andreas Hasenack andreas at canonical.com
Thu Mar 17 20:23:14 UTC 2022


On Wed, Mar 16, 2022 at 9:22 PM Martin Schwenke <martin at meltin.net> wrote:
> However, this doesn't obey the principle of least surprise, and there is
> a design flaw here. I have overloaded the meaning of variables like
> nfs_rquotad_service. There is an assumption that an unset variable
> means it is started elsewhere, which is only really true for Sys-V init.

When you say "started elsewhere", do you mean "elsewhere in ctdb", or
in the installed system?

nfs is complicated, so many services, under so many conditions
depending on what is used and what isn't.

Upstream tried to grow some smarts into the systemd service units, and
many of those start somewhat automatically when needed (like when
/etc/krb5.keytab is present - which in itself is not 100% correct all
the time, but helps).

It must be a nightmare for usptream ctdb to try to handle all of this.

> So, choices are, in nfs-linux-kernel-callout:
> 1. Insert the following in service_stop() and service_start(), before
>    each "# Default to stopping/starting by hand" comment:
>      case "$nfs_distro_style" in
>      systemd-*) return
>      esac

Why does it matter if it's systemd or sysv in this case? I'm missing
that bit of info. ctdb doesn't use systemctl, or call out to
/etc/init.d/<name> directly as far as I can tell. It only uses the
"service" call, which works for both systemd and sysv. Are you trying
to support a deployment which has neither systemd or sysv?

Why not behave like basic_start() and basic_stop(), which just skip
the service if the corresponding service variable isn't set? Sorry if
I'm missing something, I know upstream has to consider many more
deployment scenarios.

In the future maybe these variables should be factored our into a
separate (or existing) config file, and sourced by all scripts, so
that site local changes are made only there, and not in the actual
script that is run, separating data and code. Otherwise in an upgrade
which changes the script (code) there would be a config prompt (in
debian/ubuntu), and I think in rpm systems the script would be backed
up as .rpmsave, and either the old script would be run, or the new one
but without the local site changes.

More information about the samba-technical mailing list