[4.0.2] sentinels: '#Invalid argument' depending on the order of addresses in bind directive

[msoltyspl]

This is somewhat peculiar bug (or I think at least it's a bug). Originally I had the following config (after stripping comments and empty lines):

supervised systemd
pidfile "/run/redis-sentinel/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
loglevel verbose
bind 127.0.0.1 10.230.238.12
protected-mode no
port 26379
sentinel myid 3db200b46abd179e287ca0d5ab8c619324340d1c
sentinel monitor cdn 10.230.238.26 6379 2
dir "/var/lib/redis"
sentinel announce-ip 10.230.238.12
sentinel announce-port 26379

The above config resulted with sentinels unable to work correctly with following errors (on debug level) in logs:

779:X 03 Nov 12:41:24.592 . -pubsub-link-reconnection master cdn 10.230.238.26 6379 #Invalid argument
779:X 03 Nov 12:41:25.651 . -cmd-link-reconnection master cdn 10.230.238.26 6379 #Invalid argument
779:X 03 Nov 12:41:25.651 . -pubsub-link-reconnection master cdn 10.230.238.26 6379 #Invalid argument

Some quick googling revealed someone had similar issue - though a lot of time ago: https://groups.google.com/forum/#!topic/redis-db/IIY2gx33t2s - with suggested resolution to swap ip addresses in 'bind' directive:

bind 127.0.0.1 10.230.238.12 -> bind 10.230.238.12 127.0.0.1

So while it workarounds the issue, something is amiss.

The redis servers (not sentinels) were configured similarly - with explicit bind having 127.0.0.1 first followed by the 10.* address and explicit announce-ip/announce-port directives.

[morungos]

OMG. This entirely caught me and I just spent hours figuring this one out. The sentinels were simply not connecting right, and yet all the firewalls and manual connections were fine.

At the very least, this should be documented.

[itamarhaber]

@morungos I'd be more than happy to review any PR you'd make to https://github.com/antirez/redis-doc ;)