keepalived can't call notify_master script timely about keepalived HOT 4 CLOSED

There is no delay in the keepalived code between logging that the VRRP instance is entering master state and the notify_master script being run (see vrrp_state_master_tx() in keepalived/vrrp/vrrp.c). It is of course possible that the kernel suspends keepalived to schedule other processes to run, but that is outside the control of keepalived. If you suspect this is happening you could set vrrp_rt_priority nn in global_defs where nn is a suitable number between 1 and 99, which will run the keepalived vrrp process at a higher priority.

It isn't clear where the time is logged in /usr/bin/refresh-and-enable-arp, but my guess is that it is /usr/bin/refresh-arp that does that. It is therefore quite possible that /usr/bin/enable-arp is causing the delay.

The bigger problem you have is that VRRP adverts appear to be being "lost". This could be a network problem, or it could be a scheduling problem; I suggest that this is the more important problem to resolve.

from keepalived.

There is no delay in the keepalived code between logging that the VRRP instance is entering master state and the notify_master script being run (see vrrp_state_master_tx() in keepalived/vrrp/vrrp.c). It is of course possible that the kernel suspends keepalived to schedule other processes to run, but that is outside the control of keepalived. If you suspect this is happening you could set vrrp_rt_priority nn in global_defs where nn is a suitable number between 1 and 99, which will run the keepalived vrrp process at a higher priority.

It isn't clear where the time is logged in /usr/bin/refresh-and-enable-arp, but my guess is that it is /usr/bin/refresh-arp that does that. It is therefore quite possible that /usr/bin/enable-arp is causing the delay.

The bigger problem you have is that VRRP adverts appear to be being "lost". This could be a network problem, or it could be a scheduling problem; I suggest that this is the more important problem to resolve.

refresh-arp logged timestamp at the beginning, so I guess enable-arp was scheduled very lately because enable-arp is very simple, it is impossible to have a so big delay.

Is it possible VM system clock is changed at those points because of some unkown reasons?

from keepalived.

There is no delay in the keepalived code between logging that the VRRP instance is entering master state and the notify_master script being run (see vrrp_state_master_tx() in keepalived/vrrp/vrrp.c). It is of course possible that the kernel suspends keepalived to schedule other processes to run, but that is outside the control of keepalived. If you suspect this is happening you could set vrrp_rt_priority nn in global_defs where nn is a suitable number between 1 and 99, which will run the keepalived vrrp process at a higher priority.

Does vrrp_rt_priority have any side effect? Is rt scheduler policy is FIFO or RR? Will notify_master script also inherit vrrp_rt_priority?

It isn't clear where the time is logged in /usr/bin/refresh-and-enable-arp, but my guess is that it is /usr/bin/refresh-arp that does that. It is therefore quite possible that /usr/bin/enable-arp is causing the delay.

The bigger problem you have is that VRRP adverts appear to be being "lost". This could be a network problem, or it could be a scheduling problem; I suggest that this is the more important problem to resolve.

from keepalived.

Is it possible VM system clock is changed at those points because of some unkown reasons?

This seems unlikely, but I don't know what is happening on your systems.

Does vrrp_rt_priority have any side effect? Is rt scheduler policy is FIFO or RR? Will notify_master script also inherit vrrp_rt_priority?

It uses SCHED_RR. It also sets flag SCHED_RESET_ON_FORK, so notify scripts will not inherit the realtime scheduling.

I really think you need to concentrate on discovering why you are getting the following messages:

Apr 12 00:49:43 node2 Keepalived_vrrp[7989]: (VI_1) Entering MASTER STATE
Apr 12 00:49:43 node2 Keepalived_vrrp[7989]: (VI_1) Master received advert from 10.4.91.1 with higher priority 100, ours 99
Apr 12 00:49:43 node2 Keepalived_vrrp[7989]: (VI_1) Entering BACKUP STATE

Fixing these happening could well resolve the issue of the scripts being delayed in their execution.

from keepalived.