ctdb nfs rquotad: inconsistency between startup and checks

[Martin Schwenke]

Hi Andreas,

[Replying here on samba-technical, since I would like to discuss a
 fix.  I might reply to your post on the samba list, suggesting removing
 50.rquotad.check and pointing here for more details.]

First, thanks for going to the trouble of understanding the root cause
of this.  I haven't looked at this code in a long time and, even though
I wrote it, you have saved me time by refreshing my understanding.
Thanks!

On Wed, 16 Mar 2022 15:27:08 -0300, Andreas Hasenack via
samba-technical <samba-technical at lists.samba.org> wrote:

> in ctdb/config/nfs-linux-kernel-callout, nfs_rquotad_service contains
> the name of the service that starts/stops the rpc.rquotad daemon.
> 
> If that name is defined, basic_start() and basic_stop() will,
> respectively, use the service command to start/stop it. For example,
> basic_start():
> basic_start ()
> {
>     case "$1" in
>     nfs)
> ...
>         if [ -n "$nfs_rquotad_service" ] ; then
>             service "$nfs_rquotad_service" start
>         fi
> 
> 
> So if you don't define nfs_rquotad_service, it won't be started.
> 
> The nfs event script, however, behaves differently, as there is a
> specific check for rpc.rquotad in
> ctdb/config/nfs-checks.d/50.rquotad.check. Due to that check, if
> rpc.rquotad isn't running, it will be started, either via service
> $nfs_rquotad_service start, or a manual direct invocation of the
> binary.
> 
> In other words, there doesn't seem to be a way to not have rpc.rquotad
> running. Either the callout will start it, or the event script via the
> check. And if you don't have it installed, they will fail. Is this
> desired?

The simplest solution would be to remove (or edit) 50.rquotad.check on
your nodes.  Hopefully the packager has marked it as a configuration
file, so it would not be replaced on upgrade - if not, that is a
packaging bug.  Ha!  I just noticed your Canonical email address, so
you might be the packager.  :-)

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.

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

   This would avoid the hand-stop/start when systemd (and, I suppose,
   /etc/nfs.conf) is in use.  It is a hack but it should cover all
   reasonable cases.

2. Introduce a special value for variables like nfs_rquotad_service,
   such as "OFF", and treat this value specially.  This is ugly but
   effective.

3. Split the call-out into systemd and sysvinit versions.  This would
   repeat a lot of code.

I prefer (1).  Do you have an opinion?

> I'm having a problem in a scenario where the server only exports (via
> nfs) gluster mount points, for which, as far as I know, rpc.rquotad is
> useless, and I would prefer to not run it.

Makes sense.

Thanks again...

peace & happiness,
martin