VIP not released when service stopped

[ghost]

When the vip-manager service is stopped, the IP is not removed from the node. Is there a way to make this happen?

[markwort]

As a temporary workaround, you could add a call to ExecStopPost in the service file...Test if the IP is still registered on the device, if true ip addr del...

ExecStopPost=-/usr/bin/ip addr del <IP-address>/<netmask> dev <interface>
``
(with a `-` to ignore failures) would probably be enough...


Making this idea more generic requires more thought.
The deregistering routine (for whichever configurer is used) could be called whenever a SigTerm is encountered.
But we don't always want to deregister the IP when stopping the process, for example during upgrades of the vip-manager.
So something like a maintenance mode (really similar to patroni) would be needed then

[ghost]

This workaround won't work for us, as we are using a systemd target file to allow for multiple instances, as indicated here: https://github.com/cybertec-postgresql/vip-manager/issues/18

I suppose that the systemd target could somehow read in the IP & netmask from the yml file based on the target name, but I'm not really sure how feasible that is.

I think that by default vip-manager should bring down the IP when stopped, as that would be the normal expectation for a service managing a resource. Perhaps it could leave it up if killed via a specific signal?

[martinseener]

Hi, we use the vip-manger (together with patroni and consul) since november 2017 and where also a bit involved in vip-managers development. We thought about that before as well but came to the conclusion that the vip-manager should only remove the IP by itself when it can reach the consensus (etcd/consul) and see that this specific node should not have the VIP anymore. For cases like (accidential) shutdown or a process crash, the IP of the master should remain (in the case that the server with postgres still runs fine and only vip-manager crashed. We also thought that vip-manager should not remove the IP when stopped so you can easily upgrade vip-manager without moving VIPs around. Nevertheless i'm also open for a way (though a SIG) to tell vip-manager to remove the ip manually and then to stop it or create something like sysctl fullstop vip-manager which in contrast to stop would also remove the VIP.

See this issue which handles the same question: https://github.com/cybertec-postgresql/vip-manager/issues/7

What do you think?

[ghost]

I'd ultimately prefer systemctl stop vip-manager@... to release the VIP. If there's a way to make it send a custom signal on stop, that would work. It could also work to have a startup flag to indicate that when stopped normally, the VIP should be released, or alternatively, a flag to indicate that it should not release the VIP if the default is changed to release it. It's surprising behavior that the IP remains up when the service is intentionally stopped.

[markwort]

I think we shouldn't complicate this matter any more with special modes. I agree with Martin that the current behaviour (not dropping the VIP) is a good baseline for the average user.

We may however implement the option to discern the signals sent to the process. For SIGTERM (the default signal sent by systemd), the VIP will not be released. For a SIGINT, the VIP would be remove if it had been registered. (Maybe making sure that it has actually been registered by this very process).

The vip-manager could track "have I added a VIP during my runtime" and if true, remove the VIP upon SIGINT. This could also be helpful when trying to test something locally, where you might call the program directly on the shell. Pressing Ctrl+C would then make sure that the interface is also cleaned up.

On the other hand, it would be bad - if there is another vip-manager running - if somebody could remove the VIP registered by the other vip-manager just by calling vip-manager on the shell and then interrupting it. That's why I think we'd need to track if the IP has been added by the process itself.

vip-manager would be able to recover from that, since it checks if the VIP is still registered during each loop as long as it reads from DCS that it still should be registered...

Then, if you whish that the VIP is removed by default, you can set the KillSignal and RestartKillSignal accordingly in the service file. EDIT: or you can run systemctl -s SIGINT stop vip-manager to only once stop the vip-manager in such a way that it removes the VIP.

Please let me know what you think about this approach and if you forsee any possible problems (especially considering that SIGINT is sent when running the program in a shell and then pressing Ctrl+C)...

[pashagolub]

Is this issue still need our attention?

[ghost]

I guess markwort’s question may have been directed at me? I think it would be a good approach. Setting KillSignal in the service file would be an easy workaround, and I could place a modified unit file when installing vip-manager. In my workplace, the behavior of the IP staying up when vip-manager is up surprises everybody - everyone who has encountered this unusual behavior asks me about it and wants it to behave as expected.

[github-actions[bot]]

📅 This issue has been automatically marked as stale because lack of recent activity. It will be closed if no further activity occurs. ♻️ If you think there is new information allowing us to address the issue, please reopen it and provide us with updated details. 🤝 Thank you for your contributions.