Describe the bug

When there are multiple addresses to bind, such as

bind 127.0.0.1 192.168.0.1

but 192.168.0.1 isn't present, redis starts listening only to 127.0.0.1. IMO this is a configuration error which should lead to startup error. This is an issue when redis should be listening to an interface that comes up by a userspace service happening later than redis. That's of course not an issue if redis binds to 0.0.0.0, but it isn't always desirable.

I think a pretty common method is to retry the startup (systemd, supervisor, ...) and that would solve these cases pretty well. Now that redis still starts, but with the wrong configuration, this is hard to achieve. Also I would say it's pretty uncommon for a server to start with wrong bind addresses in general.

To reproduce Configure redis with

bind 127.0.0.1 some.nonexisting.ip.address

start redis

Expected behavior

Redis does not start

Actual behavior

Redis logs an error about unbindable address, but starts anyway, only listening to localhost. Happens at least with 5.0.9 and 6.0.8.

Comment From: oranagra

@lamby in #5598 you added EADDRNOTAVAIL, can you please comment here if this was indeed desired. i see that a few years earlier i already added handing for EAFNOSUPPORT (#3467), but maybe it got broken later. (didn't try to test it again / yet)

Comment From: lamby

Well, I can't imagine I would have created that PR if it were not required. :) I don't have the bandwidth to pick through and reload the exact history into my mind though, unfortunately, and I don't think I'm qualified enough to really appreciate the difference between EADDRNOTAVAIL and EAFNOSUPPORT etc .etc. Not quite my area, alas. Good luck. :+1:

Comment From: oranagra

@lamby Ok, i understand why the fix i did wasn't enough and you had to add that change. My PR ignored EAFNOSUPPORT only in case bind address wasn't specified explicitly (in which case redis tries to bind to both v4 and v6 as default), but my PR didn't ignore the error in case the v6 address was specifically requested by the config file. I thought this behavior (skipping the error in case it was explicitly requested) isn't desired, but i guess it is (considering the debian bug reports are for redis 4.0.9 and 5.0.1, and my fix was in 4.0-RC1).

Another difference is that to the request of the other issue/PR you refereed to you skipped a bunch of other errors (e.g. EPROTONOSUPPORT), but for some reason you also added EADDRNOTAVAIL (seems that this was an innocent mistake).

i'll revise it to skip only the not supported errors, and have all of them ignored for both default and explicit bind configs.