Describe the bug

Setting port 0 (and instead using TLS port numbers) maybe disables listening, but still leads to reserving port 10000. This prevents using TLS with 2 Redis instances in the same machine + properly disabling non-encrypted transactions at the same time.

To reproduce

You can easily witness this when trying to start 2 Redis servers on the same machine. Both use different tls-ports but set port 0 in their config. The first one will start as usual. The second one will refuse to start with Warning: Could not create server TCP listening socket *:10000: bind: Address already in use....

If you specify a random other port for non-encrypted connections, it will work. But that will again re-enable unencrypted traffic through that port.

Expected behavior

  1. It is odd that a port is even reserved if it isn't supposed to be used. That shouldn't happen.
  2. The mapping port 0 => leads to reserving port 10000, which makes it unusable for other applications, is IMHO undocumented.

Comment From: bashimao

Actually, I figured it out myself. The other port was listening because I had not specified tls-cluster yes. So, the communication between the two instances was still unencrypted.

It would have been cool (and saved me some time of frustrated searching) if this would have been noted in the example config at the location where the port 0 option is explained.

Comment From: ranshid

@bashimao I think the redis documentation explains the logic of port selection here. I suggest in case you want to keep traffic unencrypted on the cluster bus, it is better to use cluster-port config. It is basically possible to add feature to fail the startup in such cases (identify that the data-port is not configured, eg. set to zero), and fail in such cases, but I am not aware that this was reported as a problem before, and I guess it is possible that there are existing configurations that could be effected by it.