search for: releaseip

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

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

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

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

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

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