samba - May 2025 - ctdb tcp kill: remaining connections

Hi Uli,

On Wed, 16 Oct 2024 15:18:13 +0000, Ulrich Sibiller
<ulrich.sibiller at eviden.com> wrote:
> Martin Schwenke schrieb am 16.10.2024 04:33:
> > In this old thread, we also discussed problems with ctdb_killtcp.  The
> > patch series containing the above change also adds a script option to
> > enable use of "ss -K" for resetting TCP connections to a
public IP
> > address.  
> Can you point me to the exact location? I would like to backport this
> to my current extended script.
This is all currently up for review:

  https://gitlab.com/samba-team/samba/-/merge_requests/3840
 
> > These changes should be in the next version of Samba/CTDB.  
> 
> Thanks! I hope to being able to use a current version soon.
Of course, I meant the next minor version (e.g. 4.22.x), since none of
this is really bug fixes...

peace & happiness,
martin

Martin Schwenke schrieb am 17.10.2024 13:00:
>> Thanks! I hope to being able to use a current version soon.
> 
> Of course, I meant the next minor version (e.g. 4.22.x), since none of
> this is really bug fixes...
Unfortunately I am still not able to run the current version, but for this
problem it should not matter because the current code is unchanged in that
regard:

We are exporting GPFS filesystems with NFSv3 via ctdb. Today I have stopped ctdb
on one node, and the IPs got automatically moved to another node. This is
something that always works like a charm. However, many NFS clients started
complaining very soon, a phenomenon that we see very often:
[Mi Mai 28 13:55:24 2025] lockd: server 192.168.xxx.yy not responding, still
trying
[Mi Mai 28 13:55:24 2025] lockd: server 192.168.xxx.yy not responding, still
trying
[Mi Mai 28 13:55:24 2025] lockd: server 192.168.xxx.yy not responding, still
trying

As the IP hat already been taken over this time I manually ran ctdb gratarp
192.168.xxx.yy on the server that had taken the IP and almost immediately the
clients were fine again.

So I checked the 10.interface script and found that gratarp is only done in the
updateip case, but not in the takeip case. As we have extended that script with
some (more) logging I can say that we never see updateip being called. We only
see "monitor" and "takeip" and "releaseip". The
thing is that takeip never sends the gratarp. Even in the most current ctdb it
does not (see
https://gitlab.com/samba-team/samba/-/blame/master/ctdb/config/events/legacy/10.interface.script?ref_type=heads#L137).
So I am wondering why not?


MfG

Ulrich Sibiller
-- 
Dipl.-Inf. Ulrich Sibiller           science + computing ag
System Administration                    Hagellocher Weg 73
Hotline +49 7071 9457 681          72070 Tuebingen, Germany
https://atos.net/de/deutschland/sc