search for: gratarp

...025] 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...

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

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