SLAVE unknown state

[AutiCodes]

Support requests should be sent via https://groups.io/g/keepalived-users

Describe why you are unable to send the support request to the above email list Understanding why you cannot use the email list should help us improve it. Unable because mailserver is down

Describe what you need help/support for A clear and concise description of what you need help with. I cant get the SLAVE KeepAlived working anymore on a fresh install. I'm getting the error: (/etc/keepalived/keepalived.conf: Line 3) (VI_1) unknown state 'SLAVE', defaulting to BACKUP

Details of what you would like to do with keepalived Describe in details what you would like to achieve with keepalived It worked before, i use the Hetzner KeepAlived tutorial for a basic HA setup

Keepalived version Output of keepalived -v (a later version of keepalived might be needed). Keepalived v2.2.4 (08/21,2021)

Distro (please complete the following information):

• Name [e.g. Fedora, Ubuntu] Ubuntu
• Version [e.g. 29] 22.04
• Architecture [e.g. x86_64] X86-64

Details of any containerisation or hosted service (e.g. AWS) If keepalived is being run in a container or on a hosted service, provide full details Running on a Hetzner cloud VPS

Configuration file: Full copy of your configuration file, obfuscated if necessary to protect passwords and IP addresses

vrrp_instance VI_1 {
    interface enp7s0
    state SLAVE
    priority 100

    virtual_router_id 30
    unicast_src_ip redacted
    unicast_peer {
        redacted
    }

    authentication {
        auth_type PASS
        auth_pass redacted
    }

    notify_master /etc/keepalived/failover.sh
}

Notify and track scripts If any notify or track scripts are in use, please provide copies of them

#!/bin/bash
IP='Redacted'
TOKEN='Redacted'

n=0
while [ $n -lt 10 ]
do
    if [ "$(/opt/hcloud-ip -ip "$IP" -key $TOKEN)" == "Server called $HOSTNAME was found" ]; then
        break
    fi
    n=$((n+1))
    sleep 3
done

System Log entries Full keepalived system log entries from when keepalived started, if applicable

May 21 09:27:51 Ayumu Keepalived[1039]: Starting VRRP child process, pid=1040
May 21 09:27:51 Ayumu systemd[1]: keepalived.service: Got notification message from PID 1040, but reception only permitted for main PID 1039
May 21 09:27:51 Ayumu Keepalived_vrrp[1040]: (/etc/keepalived/keepalived.conf: Line 3) (VI_1) unknown state 'SLAVE', defaulting to BACKUP
May 21 09:27:51 Ayumu Keepalived_vrrp[1040]: WARNING - default user 'keepalived_script' for script execution does not exist - please create.
May 21 09:27:51 Ayumu Keepalived_vrrp[1040]: SECURITY VIOLATION - scripts are being executed but script_security not enabled.
May 21 09:27:51 Ayumu Keepalived_vrrp[1040]: (VI_1) No VIP specified; at least one is sensible
May 21 09:27:51 Ayumu systemd[1]: Started Keepalive Daemon (LVS and VRRP).
May 21 09:27:51 Ayumu Keepalived_vrrp[1040]: (VI_1) No VIP specified; at least one is sensible
May 21 09:27:51 Ayumu Keepalived_vrrp[1040]: (VI_1) Entering BACKUP STATE (init)
May 21 09:27:51 Ayumu Keepalived[1039]: Startup complete

Additional context Add any other context about the problem here. It worked fine some time ago on the original HA cluster

[pqarmitage]

A quick answer is that the state keyword doesn't really do anything. Since the priority is < 255, the VRRP instance will start up in BACKUP state.

I will do a search for what happened to the "SLAVE" option and upgrade this issue.

[pqarmitage]

Prior to commit 40e4a17 for the state keyword the code checked for MASTER but any other string configured for the state would (silently) set the initial state to BACKUP. Commit 40e4a17 added a check for the state option specified, and logged a warning if an unknown state (e.g. SLAVE) was specified, but the functionality wasn't otherwise altered, i.e. anything other than MASTER causedm and still causes, the initial state to be BACKUP.