search for: takeip

...l 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:...

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

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

Hey all, I am trying to figure out a weird problem. I have a two node ctdb samba setup where the first node acts as expected setting the default gateway (startup shutdown takeip recoveryip) if there is a network blip / link down, but the second node does not set the default gateway properly on the initial recovery of the link after the blip has occurred. If I restart the machine or restart the ctdb service, then it does come back with the proper gateway and traffic flows...

...he last point in time is the one where I saw the remaining connections: Feb 13 12:08:11 serverpnn1 ctdbd[85617]: ../../ctdb/server/eventscript.c:655 Running event releaseip with arguments team1 x.x.253.252 24 Feb 13 12:16:26 serverpnn1 ctdbd[85617]: ../../ctdb/server/eventscript.c:655 Running event takeip with arguments team1 x.x.253.252 24 Feb 13 12:27:50 serverpnn1 ctdbd[85617]: ../../ctdb/server/eventscript.c:655 Running event releaseip with arguments team1 x.x.253.252 24 So if the first releaseip could not clear all connections they might pile up... > So, for your NFS clients, it will attem...

Hi Martin, Thanks for your answer... >> I am using the 10.external. ip addr show shows the correct IP addresses >> on eth0 in the lxc container. rebooted the physical machine, this node >> is buggered. shut it down, used ip addr add to put the addresses on the >> other node, used ctdb addip and the node took it and node1 is now >> functioning with all 4 IPs just

...nt in time is the one where I saw the remaining connections: > Feb 13 12:08:11 serverpnn1 ctdbd[85617]: ../../ctdb/server/eventscript.c:655 Running event releaseip with arguments team1 x.x.253.252 24 > Feb 13 12:16:26 serverpnn1 ctdbd[85617]: ../../ctdb/server/eventscript.c:655 Running event takeip with arguments team1 x.x.253.252 24 > Feb 13 12:27:50 serverpnn1 ctdbd[85617]: ../../ctdb/server/eventscript.c:655 Running event releaseip with arguments team1 x.x.253.252 24 OK, it could be a failback problem. > No, no smb, only nfsv3. Port 599 is the lockd: > [...] OK. > > Thi...

Hi Uli, [Sorry for slow response, life is busy...] On Mon, 13 Feb 2023 15:06:26 +0000, Ulrich Sibiller via samba <samba at lists.samba.org> wrote: > we are using ctdb 4.15.5 on RHEL8 (Kernel > 4.18.0-372.32.1.el8_6.x86_64) to provide NFS v3 (via tcp) to RHEL7/8 > clients. Whenever an ip takeover happens most clients report > something like this: > [Mon Feb 13 12:21:22