I may have stumbled upon a bug in the code that handles getting sync
daemon status via the netlink interface. This could also be a bug in
ipvsadm, depending on how the code it expected to behave.
When getting the sync daemon status, there can be at most two
ipvs_daemon_t entries returned -- one for master, one for backup. It
appears that the old getsockopt method for retrieving sync daemon status
would *always* put the results for the master daemon (if any) in the
first entry and the backup (if any) in the second entry. If you only
have a backup daemon running, the first entry would be empty and the
second entry would contain the status of the backup daemon.
The netlink interface for retrieving sync daemon status does not have
the same semantics. If you only have a backup daemon running, the status
will be in the first entry and the second entry will be empty.
This problem shows up in ipvsadm because it expects the master daemon
status to always be at index 0 and the backup daemon status at index 1.
The result is that 'ipvsadm --list --daemon' will not report a backup
daemon if only a backup daemon is running and ipvsadm is compiled to use
the netlink interface.
This is really simple to fix in ipvsadm. I have a patch that checks
either entry of the results for active/backup state, but I first wanted
to check that the behavior of the netlink IPVS_CMD_GET_DAEMONS command
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html