Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve error checking of the bind() call on ipv6 sockets #4108

Closed
wants to merge 1 commit into from
Closed

Improve error checking of the bind() call on ipv6 sockets #4108

wants to merge 1 commit into from

Conversation

jaromil
Copy link

@jaromil jaromil commented Jul 7, 2017

Extend the error check to EPROTONOSUPPORT to which errno is set in
certain contexts (especially some containers) and to other error codes
which may be reported in more situations, adopting the same list used
in the ISC DHCP implementation upon socket() and bind() calls.

Solves issue #3894

@jaromil jaromil mentioned this pull request Jul 7, 2017
Closed
@jaromil jaromil force-pushed the unstable branch 2 times, most recently from feec660 to 8a251cc Compare July 7, 2017 08:09
@jaromil
Improve error checking of the bind() call on ipv6 sockets
8a251cc 
Extend the error check to EPROTONOSUPPORT to which errno is set in
certain contexts (especially some containers) and to other error codes
which may be reported in more situations, adopting the same list used
in the ISC DHCP implementation upon socket() and bind() calls.
lamby added a commit to lamby/redis that referenced this pull request Nov 23, 2018
@lamby
Don't treat unsupported protocols as fatal errors
fbff351 
If we encounter an unsupported protocol in the "bind" list, don't
ipso-facto consider it a fatal error. We continue to abort startup if
there are no listening sockets at all.

This ensures that the lack of IPv6 support does not prevent Redis from
starting on Debian where we try to bind to the ::1 interface by default
(via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some
container systems) would simply fail to start Redis after the initiall
call to apt(8).

This is similar to the case for where "bind" is not specified:

  redis#3894

... and was based on the corresponding PR:

  redis#4108

... but also adds EADDRNOTAVAIL to the list of errors to catch which I
believe is missing from there.

This issue was raised in Debian as both <https://bugs.debian.org/900284>
& <https://bugs.debian.org/914354>.
@lamby lamby mentioned this pull request Nov 23, 2018
Merged
@lamby
Copy link
Contributor

lamby commented Nov 23, 2018

I think this is also missing EADDRNOTAVAIL for the case of binding ::1. (re. #3894, via #5598)

antirez pushed a commit that referenced this pull request Dec 11, 2018
@lamby @antirez
Don't treat unsupported protocols as fatal errors
fefe546 
If we encounter an unsupported protocol in the "bind" list, don't
ipso-facto consider it a fatal error. We continue to abort startup if
there are no listening sockets at all.

This ensures that the lack of IPv6 support does not prevent Redis from
starting on Debian where we try to bind to the ::1 interface by default
(via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some
container systems) would simply fail to start Redis after the initiall
call to apt(8).

This is similar to the case for where "bind" is not specified:

  #3894

... and was based on the corresponding PR:

  #4108

... but also adds EADDRNOTAVAIL to the list of errors to catch which I
believe is missing from there.

This issue was raised in Debian as both <https://bugs.debian.org/900284>
& <https://bugs.debian.org/914354>.
JackieXie168 pushed a commit to JackieXie168/redis that referenced this pull request Dec 17, 2018
@lamby
Don't treat unsupported protocols as fatal errors
165fe6f 
If we encounter an unsupported protocol in the "bind" list, don't
ipso-facto consider it a fatal error. We continue to abort startup if
there are no listening sockets at all.

This ensures that the lack of IPv6 support does not prevent Redis from
starting on Debian where we try to bind to the ::1 interface by default
(via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some
container systems) would simply fail to start Redis after the initiall
call to apt(8).

This is similar to the case for where "bind" is not specified:

  redis#3894

... and was based on the corresponding PR:

  redis#4108

... but also adds EADDRNOTAVAIL to the list of errors to catch which I
believe is missing from there.

This issue was raised in Debian as both <https://bugs.debian.org/900284>
& <https://bugs.debian.org/914354>.
antirez pushed a commit that referenced this pull request Dec 21, 2018
@lamby @antirez
Don't treat unsupported protocols as fatal errors
afc4b36 
If we encounter an unsupported protocol in the "bind" list, don't
ipso-facto consider it a fatal error. We continue to abort startup if
there are no listening sockets at all.

This ensures that the lack of IPv6 support does not prevent Redis from
starting on Debian where we try to bind to the ::1 interface by default
(via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some
container systems) would simply fail to start Redis after the initiall
call to apt(8).

This is similar to the case for where "bind" is not specified:

  #3894

... and was based on the corresponding PR:

  #4108

... but also adds EADDRNOTAVAIL to the list of errors to catch which I
believe is missing from there.

This issue was raised in Debian as both <https://bugs.debian.org/900284>
& <https://bugs.debian.org/914354>.
JohnSully pushed a commit to Snapchat/KeyDB that referenced this pull request Feb 23, 2019
@lamby
Don't treat unsupported protocols as fatal errors
99c2604 
If we encounter an unsupported protocol in the "bind" list, don't
ipso-facto consider it a fatal error. We continue to abort startup if
there are no listening sockets at all.

This ensures that the lack of IPv6 support does not prevent Redis from
starting on Debian where we try to bind to the ::1 interface by default
(via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some
container systems) would simply fail to start Redis after the initiall
call to apt(8).

This is similar to the case for where "bind" is not specified:

  redis/redis#3894

... and was based on the corresponding PR:

  redis/redis#4108

... but also adds EADDRNOTAVAIL to the list of errors to catch which I
believe is missing from there.

This issue was raised in Debian as both <https://bugs.debian.org/900284>
& <https://bugs.debian.org/914354>.
@oranagra
Copy link
Member

solved by #5598 (redis 5.0.3) and improved by #7936

@oranagra oranagra closed this Oct 21, 2020
pulllock pushed a commit to pulllock/redis that referenced this pull request Jun 28, 2023
@lamby @antirez
Don't treat unsupported protocols as fatal errors
7fa06cf 
If we encounter an unsupported protocol in the "bind" list, don't
ipso-facto consider it a fatal error. We continue to abort startup if
there are no listening sockets at all.

This ensures that the lack of IPv6 support does not prevent Redis from
starting on Debian where we try to bind to the ::1 interface by default
(via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some
container systems) would simply fail to start Redis after the initiall
call to apt(8).

This is similar to the case for where "bind" is not specified:

  redis#3894

... and was based on the corresponding PR:

  redis#4108

... but also adds EADDRNOTAVAIL to the list of errors to catch which I
believe is missing from there.

This issue was raised in Debian as both <https://bugs.debian.org/900284>
& <https://bugs.debian.org/914354>.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@jaromil @lamby @oranagra