keepalived 1.2.17 calls notify script twice when it starts in MASTER state about keepalived HOT 5 CLOSED

well I am going to revert 2 patch related to notify since implementation is not tested.

from keepalived.

Just reverted all changes related to script... please give it a try and report... Old syntax declaration is back. (eg: notify /tmp/katest.sh)

from keepalived.

In my simple test case, this fix seems to work. Thanks.

Stupid question -- when there are syntax errors in the configuration file, why doesn't keepalived print an error message and exit? For example, if notify requires curly braces, and they're not present, as was the case until the patch was reverted, why didn't keepalived abort at startup? Similarly, if I now run this version with curly braces still present, it does not complain. It seems like it would be an improvement if the config file parser were to throw a fatal error when the grammar is violated.

Regards,
Andy

from keepalived.

By the way, the bug where keepalived fails to remove VRRP addrs when stopped is still there. Are you aware of that one?

Using LinkWatch kernel netlink reflector...
VRRP sockpool: [ifindex(5), proto(112), unicast(0), fd(10,11)]
VRRP_Instance(pcr-ny4-mktdata-relay) Transition to MASTER STATE
VRRP_Instance(pcr-ny4-mktdata-relay) Entering MASTER STATE
VRRP_Instance(pcr-ny4-mktdata-relay) setting protocol VIPs.
VRRP_Instance(pcr-ny4-mktdata-relay) Sending gratuitous ARPs on lan0.3003 for 192.168.53.250
Opening script file /tmp/katest.sh
VRRP_Instance(pcr-ny4-mktdata-relay) Sending gratuitous ARPs on lan0.3003 for 192.168.53.250
^CStopping Keepalived v1.2.17 (06/18,2015)

But 192.168.53.250 is still there:

bash-4.3$ ip -4 addr ls dev lan0.3003
5: lan0.3003@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
inet 192.168.53.139/24 brd 192.168.53.255 scope global lan0.3003
valid_lft forever preferred_lft forever
inet 192.168.53.250/24 brd 192.168.53.255 scope global secondary lan0.3003
valid_lft forever preferred_lft forever

This bug has been around for years...

from keepalived.

regarding stupid question :) : Well, current configuration parser is just not good enough :), I am into a process to completely rewrite that noisy parser. Jan Holmberg already produced some investigation code, I will dig into and produce new stuff around this area.

from keepalived.