search for: releaseip

Displaying 9 results from an estimated 9 matches for "releaseip".

Did you mean: release_ip
2023 Feb 16
1
ctdb tcp kill: remaining connections
...e failover. Hmm, that node where above output was seen hat released and taken that very ip shortly before. And then released it again. The 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...
2025 May 28
1
ctdb tcp kill: remaining connections
...n. 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 Sib...
2023 Feb 15
1
ctdb tcp kill: remaining connections
...;nfsserver> ctdb-eventd[85619]: 10.interface: x.x.253.252:2049 x.x.253.177:814 > ... > The log (which I unfortunately do not have anymore) showed 405 of > those "Sending a TCP RST" lines in a row which is more than the > reported 394. > This output is coming from the releaseip section in > /etc/ctdb/events/legacy/10.interface, which calls > kill_tcp_connections (in /etc/ctdb/functions) which calls the > ctdb_killtcp utility to actually kill the connections. This happens > inside a block_ip/unblock_ip guard that temporarily sets up a > firewall rule to drop...
2023 Feb 16
1
ctdb tcp kill: remaining connections
..., that node where above output was seen hat released and taken > that very ip shortly before. And then released it again. The 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 tea...
2024 Oct 17
1
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
2023 Feb 13
1
ctdb tcp kill: remaining connections
...3:810 Feb 13 12:27:55 <nfsserver> ctdb-eventd[85619]: 10.interface: x.x.253.252:2049 x.x.253.177:814 ... The log (which I unfortunately do not have anymore) showed 405 of those "Sending a TCP RST" lines in a row which is more than the reported 394. This output is coming from the releaseip section in /etc/ctdb/events/legacy/10.interface, which calls kill_tcp_connections (in /etc/ctdb/functions) which calls the ctdb_killtcp utility to actually kill the connections. This happens inside a block_ip/unblock_ip guard that temporarily sets up a firewall rule to drop all incoming packages fo...
2023 Mar 09
1
ctdb tcp kill: remaining connections
...NFSv3. > True, but for a basic understanding of what happened, it could be good > to just use INFO level. Right now, I think you're doing developer > level debugging. ;-) Yes, I agree ? > We are in violent agreement! :-) ? > The main problem is the code in 10.interface releaseip is only run when > the "releasing" node does not crash hard. So, we need another method. > > The port number is tricky because we need to support both kernel NFS > and NFS Ganesha. We could add it to the call-out... but I'm not sure > it would be easy. Probably bett...
2025 May 29
1
ctdb tcp kill: remaining connections
...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? In the "takeip" case t...
2017 Nov 08
1
ctdb vacuum timeouts and record locks
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