NGINX fails to start/install/upgrade if IPv6 is completely disabled.

Bug #1743592 reported by Thomas Ward on 2018-01-16
28
This bug affects 2 people
Affects Status Importance Assigned to Milestone
nginx (Debian)
New
Unknown
nginx (Ubuntu)
Wishlist
Thomas Ward
Xenial
Medium
Unassigned
Bionic
Medium
Unassigned
Disco
Medium
Unassigned
Eoan
Medium
Unassigned

Bug Description

[IMPACT]

With current default vhost listening on IPV6, nginx won't start on fully IPV6 disabled system, expecting to connect to a IPV6 socket on port 80.

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
==> nginx: [emerg] socket() [::]:80 failed (97: Address family not supported by protocol)
nginx: configuration file /etc/nginx/nginx.conf test failed

# cat /etc/nginx/sites-enabled/default
......
server {
 listen 80 default_server;
==> listen [::]:80 default_server;
......

[TEST CASE]
* Disable ipv6
  # cat /proc/cmdline
  .... ipv6.disable=1

* Reboot for the kernel parameter to be taken into account.

* Fresh install of nginx:
  # apt-get install nginx -y

Output:
--------

# apt-get install nginx -y
.......................
Setting up nginx-core (1.14.0-0ubuntu1.6) ...
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nginx, action "start" failed.
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-10-23 14:01:26 UTC; 6ms ago
     Docs: man:nginx(8)
  Process: 1005 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

Oct 23 14:01:26 nginxbionictest1 systemd[1]: Starting A high performance web server and a reverse proxy server...
Oct 23 14:01:26 nginxbionictest1 nginx[1005]: nginx: [emerg] socket() [::]:80 failed (97: Address family not supported by protocol)
Oct 23 14:01:26 nginxbionictest1 nginx[1005]: nginx: configuration file /etc/nginx/nginx.conf test failed
Oct 23 14:01:26 nginxbionictest1 systemd[1]: nginx.service: Control process exited, code=exited status=1
Oct 23 14:01:26 nginxbionictest1 systemd[1]: nginx.service: Failed with result 'exit-code'.
Oct 23 14:01:26 nginxbionictest1 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
dpkg: error processing package nginx-core (--configure):
 installed nginx-core package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of nginx:
 nginx depends on nginx-core (<< 1.14.0-0ubuntu1.6.1~) | nginx-full (<< 1.14.0-0ubuntu1.6.1~) | nginx-light (<< 1.14.0-0ubuntu1.6.1~) | nginx-extras (<< 1.14.0-0ubuntu1.6.1~); however:
  Package nginx-core is not configured yet.
  Package nginx-full is not installed.
  Package nginx-light is not installed.
  Package nginx-extras is not installed.
 nginx depends on nginx-core (>= 1.14.0-0ubuntu1.6) | nginx-full (>= 1.14.0-0ubuntu1.6) | nginx-light (>= 1.14.0-0ubuntu1.6) | nginx-extras (>= 1.14.0-0ubuntu1.6); however:
  Package nginx-core is not configured yet.
  Package nginx-full is not installed.
  Package nginx-light is not installed.
  Package nginx-extras is not installed.

dpkg: error processing package nginx (--configure):
 dependency problems - leaving unconfigured
Processing triggers for systemd (237-3ubuntu10.31) ...
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for ufw (0.36-0ubuntu0.18.04.1) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Errors were encountered while processing:
 nginx-core
 nginx
E: Sub-process /usr/bin/dpkg returned an error code (1)

# dpkg -l | grep -i nginx
iU nginx 1.14.0-0ubuntu1.6 all small, powerful, scalable web/proxy server
ii nginx-common 1.14.0-0ubuntu1.6 all small, powerful, scalable web/proxy server - common files
iF nginx-core 1.14.0-0ubuntu1.6 amd64 nginx web/proxy server (standard version)

--------

[REGRESSION POTENTIAL]

LOW.

Other distributions does that (not including ipv6 listen by default) already (e.g. Centos and Upstream)

* nginx.vh.default.conf -> "nginx-1.16.0-1.el8.ngx.src.rpm"
server {
    listen 80;
    server_name localhost;

* Upstream nginx:
https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L36

This won't introduce behaviour change for those who upgrade nginx, but it will introduce a behaviour change for those used to have ipv6 listen in the default vhost at fresh package installation.

But IMHO, the default vhost is a starting point/example, that the admin will anyway have to modify manually or via some automation tool (ansible, chef, puppet, ...)

So this will only imply that the admin will need to update their recipe to add the ipv6 listen in their vhost config (ONLY if needed).

Minus leaving the users to have to uncomment the ipv6 listen in the vhost (if needed) by themselves manually, automation recipes, ... I don't see any major blocker, I personally think it's a good compromise in order to prevent the actual package to fails and be found in a erroneous state if ipv6 is disabled.

Of course, we can debate if disabling ipv6 is a good or wrong, but I think that the package installation should succeed for both ipv4only and ipv6.

[OTHER INFORMATION]

* Debian upstream bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942817

[ORIGINAL DESCRIPTION]
There is a known issue where NGINX will not properly run or install when IPv6 is fully disabled on a system.

Per Bug #1712696 which first detailed this, these are some 'relevant' log entries:

Aug 23 23:52:24 thomas-ThinkPad-T430 nginx[20166]: nginx: [emerg] socket() [::]:80 failed (97: Address family not supported by protocol)
Aug 23 23:52:24 thomas-ThinkPad-T430 nginx[20166]: nginx: configuration file /etc/nginx/nginx.conf test failed
Aug 23 23:52:24 thomas-ThinkPad-T430 systemd[1]: nginx.service: Control process exited, code=exited status=1
Aug 23 23:52:24 thomas-ThinkPad-T430 systemd[1]: Failed to start A high performance web server and a reverse proxy server.

As you can see the system could not bind to Port 80 on IPv6.

While this is a **nonstandard** setup, there are some systems which are configured to not have IPv6 support. It should currently be considered whether we should test for such 'systems' to see whether IPv6 is enabled or not, and modify the configuration file accordingly during install/configure.

This issue happens regardless of the 'supported' operating system status or not, and is a core NGINX package issue, but also a core 'incompatible configuration' issue with systems which disable IPv6.

Tags: sts Edit Tag help
Thomas Ward (teward) on 2018-01-16
description: updated
Thomas Ward (teward) on 2019-07-31
summary: - NGINX fails to install/upgrade if IPv6 is completely disabled.
+ NGINX fails to start/install/upgrade if IPv6 is completely disabled.
Eric Desrochers (slashd) wrote :
tags: added: sts
Changed in nginx (Debian):
status: Unknown → New
Eric Desrochers (slashd) wrote :

So IMHO there is 2 ways to fix this:

(1) - We remove the ipv6 listen from the vhost (just like Centos/Upstream does atm)

# nginx.vh.default.conf -> "nginx-1.16.0-1.el8.ngx.src.rpm"
server {
    listen 80;
    server_name localhost;

So as upstream nginx:
https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L36

This won't introduce behaviour change for those who upgrade nginx, but it will introduce a behaviour change for those used to have ipv6 listen in the default vhost at fresh package installation.

But IMHO, the default vhost is a starting point/example, that the admin will anyway have to modify manually or via some orchestration tool (ansible, chef, puppet, ...)

So this will only imply that the admin will need to update their recipe to add the ipv6 listen in the vhost. I don't see any big blocker here.

(2) We implement a ipv6 detection as describe in the debian bug and provide a noipv6 vhost and/or a ipv6 vhost depending if ipv6 is [en|dis]abled on the system. But for me, that seems hacky.

I have a preference for scenario #1.

I have proposed both scenarios to debian, let's see what they say. In the absence of response from their part, I'll have SRU scenario #1 into Ubuntu.

I'll give debian maintainer team a week or so before.

- Eric

Changed in nginx (Ubuntu):
assignee: Thomas Ward (teward) → Eric Desrochers (slashd)
status: Triaged → In Progress
Eric Desrochers (slashd) on 2019-10-23
description: updated
description: updated
description: updated
Changed in nginx (Ubuntu Eoan):
assignee: nobody → Eric Desrochers (slashd)
Changed in nginx (Ubuntu Disco):
assignee: nobody → Eric Desrochers (slashd)
Changed in nginx (Ubuntu Bionic):
assignee: nobody → Eric Desrochers (slashd)
Changed in nginx (Ubuntu Xenial):
assignee: nobody → Eric Desrochers (slashd)
Eric Desrochers (slashd) on 2019-10-23
description: updated
Thomas Ward (teward) wrote :

I am in favor of solution #1, and will drive this for Focal. However, I have no call in whether this is accepted by the SRU team for SRU.

More to come though, I have a priority on the nginx package in Focal and determining which branch we track heading up to release first.

Eric Desrochers (slashd) wrote :

@teward, sound good I'll let you drive the focal upload since you were already in the middle of it and include solution #1 in it.

For the SRU, I'll take care of the discussion internally, and will keep the bug updated on the outcome.

Eric

Changed in nginx (Ubuntu):
assignee: Eric Desrochers (slashd) → Thomas Ward (teward)
Changed in nginx (Ubuntu Eoan):
status: New → In Progress
importance: Undecided → Medium
Changed in nginx (Ubuntu Disco):
status: New → In Progress
Changed in nginx (Ubuntu Bionic):
status: New → In Progress
importance: Undecided → Medium
Changed in nginx (Ubuntu Disco):
importance: Undecided → Medium
Eric Desrochers (slashd) on 2019-10-26
description: updated
description: updated
Eric Desrochers (slashd) on 2019-10-26
description: updated
Robie Basak (racb) wrote :

If I understand the situation correctly, my subjective opinion is that I don't think a "fix" for this is suitable for an SRU, but I welcome discussion if you disagree.

It's not uncommon to come across a situation where the user configures the system in some non-default way in one configuration file, and something else breaks without the user altering some other configuration file.

A couple of unrelated examples of this pattern:

1) A user configures a service to bind to a specific address, but then finds that the service fails to start because this introduces a dependency on having an interface with that address configured first. In this example the service hasn't been written to handle the interface coming up after service start, which would be the ideal solution to the problem. In the meantime, the user needs to also configure the init system to order the service start after the interface configuration.

2) A user configures a service to use a non-standard filesystem location, but then finds that AppArmor blocks access to that location. The user needs to also adjust the AppArmor profile to permit access to that location.

So here we have (I think):

3) A user disables IPv6. The user also needs to adjust the nginx configuration to not attempt to bind to IPv6 addresses.

In all of these cases, I agree that it would be nice if the appropriate thing could automatically detect the other configuration change and adjust itself accordingly by default. Doing this would certainly be a valuable usability improvement. However, I don't think these are bugs as such; this is expected behaviour albeit that the expected behaviour could be improved upon. While we might be able to make individual enhancements, in the general case it's clearly impossible to infer every possible necessary adjustment automatically. In the meantime, a user who adjusts away from default configuration in one place is expected to adjust other dependent configuration to match.

My conclusion is that this is a valid Wishlist-level bug in that in this specific case it would be nice if the default nginx configuration would continue to work without needing adjustment to match the global IPv6 disablement. However, for the reasons above I don't think an SRU is warranted, since the current behaviour is expected behaviour and doesn't prevent the user from achieving what they want. The currently correct way of handling this is to adjust nginx configuration, which is possible without needing any changes to the existing packaging.

I appreciate the efforts to make this experience better for users. That should take effect in future releases (but not change behaviour in existing stable releases). I therefore propose "Won't Fix" for the Ubuntu stable release bug tasks.

Thomas Ward (teward) on 2019-10-28
Changed in nginx (Ubuntu):
status: In Progress → Triaged
importance: Low → Medium
importance: Medium → Low
Eric Desrochers (slashd) on 2019-10-28
Changed in nginx (Ubuntu Eoan):
status: In Progress → Won't Fix
Changed in nginx (Ubuntu Disco):
status: In Progress → Won't Fix
Changed in nginx (Ubuntu Bionic):
status: In Progress → Won't Fix
Changed in nginx (Ubuntu Xenial):
status: New → Won't Fix
Eric Desrochers (slashd) on 2019-10-28
Changed in nginx (Ubuntu Xenial):
assignee: Eric Desrochers (slashd) → nobody
Changed in nginx (Ubuntu Bionic):
assignee: Eric Desrochers (slashd) → nobody
Changed in nginx (Ubuntu Eoan):
assignee: Eric Desrochers (slashd) → nobody
Changed in nginx (Ubuntu Disco):
assignee: Eric Desrochers (slashd) → nobody
Thomas Ward (teward) on 2019-11-01
Changed in nginx (Ubuntu):
status: Triaged → In Progress
importance: Low → Medium
Changed in nginx (Ubuntu Xenial):
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nginx - 1.17.5-0ubuntu1

---------------
nginx (1.17.5-0ubuntu1) focal; urgency=medium

  * New upstream release (1.17.5) - full changelog available from
    http://nginx.org/en/CHANGES
  * Remaining Ubuntu-specific changes:
    - debian/patches/ubuntu-branding.patch: add Ubuntu branding (refreshed)
    - d/{control,rules,nginx-core.*}: add new binary package for main,
      nginx-core, which contains only source-tarball-included modules
      and no third-party modules.
    - debian/tests/control: add nginx-core test.
    - debian/apport/source_nginx.py: Add apport hooks for additional bug
      information gathering.
    - debian/nginx-common.install: Add install rule for apport hooks.
    - d/nginx-{core,light,full,extras}.postinst: Add checks for whether
      port 80 is in use or not to determine whether or not to attempt
      starting of the NGINX service during install/upgrade
    - d/control: Add dependencies to nginx-{core,light,full,extras} on
      `iproute2` as the postinst scripts now use `ss` to determine if
      Port 80 is open or not.
    - d/rules: Enable --with-compat build option for all nginx package
      flavors
    - d/{control,rules,copyright,modules/http-geoip2*}: Add GeoIP2 third party
      module to nginx-full and nginx-extras (and use proper DEP5 syntax for
      d/copyright).
  * New Ubuntu-specific changes:
    - d/conf/sites-available/default: Update default nginx site configuration
      file to remove the IPv6 listening line so that servers running without
      IPv6 enabled at all on the system will start nginx properly.
      (LP: #1743592)

 -- Thomas Ward <email address hidden> Fri, 01 Nov 2019 11:55:10 -0400

Changed in nginx (Ubuntu):
status: In Progress → Fix Released
T Jeske (t-jeske) wrote :

Opting for #1 is a stupid idea.

Yes, personally I hate it because many times I have been wondering why it's not listening on IPv6 only to find out that the configuration line "listen 80 default_server;" doesn't in fact mean to just listen on port 80, but to listen only on port 80 for IPv4. In my opinion this configuration line doesn't make it clear, and if it stays like this, then "#listen [::]:80 default_server;" needs to be included in this way at the very least (note the hash symbol)!

What is another problem is hosting providers that are dual-stacked, and where maybe AAAA-records already exist. In those cases the client would first try to connect to the IPv6 address which has no nginx listening on port 80. Happy eyeballs should take care of this and fallback to IPv4, but that doesn't always seem to work properly.

On another note this is another step towards cannibalizing the deployment of IPv6 by making it opt-in instead of opt-out. Either implement option #2 or return to the way it was before and leave it up to the admin to figure out why his config doesn't work on the system he fiddled with.

Thomas Ward (teward) wrote :

T Jeske:

That needs its own bug tracking to try and change the functionality. It also needs broader discussions as well outside of here.s

Thomas

Wilco Baan Hofman (wilco) wrote :

So from now on my IPv6-only installs will not work? That's just great, let's go back to 1992, when IPv6 did not exist yet.

I should create a bug for this..

If you disable IPv6, expect your system not to work. This is the 21st century. My systems don't even have 127.0.0.1 anymore, only ::1 and guess what. Modern software just deals with it.

I consider this a huge regression.

Kevin Otte (nivex) wrote :

IPv6 should not be completely disabled on any system. This is not in keeping with Best Current Practices. See RFC 6540 (BCP 177). If an admin has manually disabled IPv6 on their system, it is their responsibility to also disable any services listening on IPv6 by default. This "fix" is antithetical to a modern Internet.

Kamilion (kamilion) wrote :

This change would break IPv6 support for nginx on all of my ISO spins. It's also doubly aggravating that edits to nginx.conf drive apt up the wall asking for 3 way merges; so I simply stopped editing nginx.conf and moved to using nginx/conf.d for *everything* because it kept breaking unattended-upgrades.

Thomas Ward (teward) wrote :

This will be reverted in an upload tomorrow.

Kamilion (kamilion) wrote :

Hm. After thinking about this a little, perhaps there is a way to have cake and consume it justly.
Since `ss` is now being used to check ports, I suggest a postinst check with `ss -6` to see if the icmp6 entry exists or not. If it does not exist, write a marker file out on disk that ipv6-appears-disabled. Check the marker during each postinst and select between the two "default" conditions automatically. Duplicate the `sites-available/default` with an additional copy `sites-available/default-ipv6`, with the inverse listen commented out, and the appropriate sites-enabled symlink. If either symlink is removed, the postinst doesn't recreate it.

This way `default` remains true to upstream, while the debian/ubuntu ipv6 listen addition is obvious to any operators. A quirk like this could easily be pointed out in the focal release notes as an ubuntuism.

As far as I am aware, during deployments of nginx by site operators it is common to remove the `sites-enabled/default` symlink to disable it without apt freaking out about 3 way merges.

Currently, I don't even utilize the sites-available or sites-enabled at all with my ISO spins.
The last line in my `/etc/nginx/conf.d/autoconfig.conf` is:

`include /opt/project/*/resources/latest/config/http/*/*.conf;`

It would be no trouble at all for me to add the scripted removal of the `sites-enabled/default-ipv6` symlink alongside my existing scripted removal of `sites-enabled/default`.

Means a slightly mungier postinst; but appropriate comments detailing the idea there would go a long way.

T Jeske (t-jeske) wrote :

Thomas Ward:

Which part are you referring to exactly?

I agree automating the detection of everything seems a bit over the top. But for something so fundamental as the different IP-stacks, I think it is well worth considering it, though I am also not really happy as I still believe whoever disables IPv6 system-wide should consider the consequences.

T Jeske (t-jeske) wrote :

Addition: Actually I think the best solution would be to test for IPv6 at runtime and produce just a warning instead of failing. Same for systems where IPv4 is disabled but the config still contains the IPv4 directive.

Any objections?

Simon Déziel (sdeziel) wrote :

Using a single "listen [::]:80 default_server ipv6only=off;" seems to do the right thing in all situations: IPv4-only, IPv6-only or dual-stack.

The drawback of using this single socket is that IPv4 clients have their IPs represented as IPv4-Mapped IPv6 in access_log:

==> /var/log/nginx/access.log <==
::ffff:10.139.167.1 - - [20/Feb/2020:17:15:25 +0000] "GET / HTTP/1.1" 200 612 "-" "Wget/1.19.4 (linux-gnu)"

That said, if you go to extra lengths to disable IPv6 on your box, why not also tune the default vhost? Your config is already not aligned with the default of IPv6 enabled :)

Thomas Ward (teward) wrote :

Upon additional discussion among the Server Team, we have come to this conclusion:

The changes introduced as a result of this bug are no longer valid and are going to be reverted in the next upload of NGINX to the repositories.

For 20.04, we do not want to introduce additional complexity at this time to the postinst logic to 'alter' the default file depending on if IPv4 or IPv6 are actually available. Further, we do not want to break 'default log parsing' by using the solution that was provided by sdeziel.

Because we are *reverting* this change, I am setting the bug's status to "Opinion" - at a later time we may introduce something which actually fixes this problem in the future.

Changed in nginx (Ubuntu):
status: Fix Released → Opinion
Thomas Ward (teward) on 2020-02-20
Changed in nginx (Ubuntu):
status: Opinion → Triaged
importance: Medium → Wishlist
Robie Basak (racb) wrote :

To clarify what just happened:

nginx should serve on IPv6 by default, just as IPv6 is available on Ubuntu by default. The previous upload broke this, so this revert restores it. Thank you to all who participated in the discussion.

The default nginx configuration will fail if IPv6 is disabled, as before. This is unfortunate, and this experience could be improved, so this bug remains open.

If you wish to disable IPv6, you must currently also adjust service configuration to match. While this could be improved and we are open to discussion on how to achieve that, the current situation is by design, so I suggested that the bug should be Wishlist to Thomas.

Nothing prevents a user from disabling IPv6. Just that if you do, you must also adjust some services to not listen on IPv6. Another way of looking at this is that adjusting those services is part of "disabling IPv6".

Dan Streetman (ddstreet) wrote :

For those coming here because their installation or upgrade of the 'nginx' package fails due to their system using ipv6.disabled=1, you need to edit the file "/etc/nginx/sites-enabled/default" and remove or comment out this line:

        listen [::]:80 default_server;

Alternately, you can remove that file completely (it is actually a symlink to "/etc/nginx/sites-available/default"). However, you will of course need to create your own nginx configuration, for it to do anything useful.

Then you can restart the nginx service with:
$ sudo systemctl restart nginx
or just reboot.

You will also need to fix your broken installation of nginx:

$ sudo apt install --fix-broken

Note that apt may complain with a warning like:

W: APT had planned for dpkg to do more than it reported back (3 vs 7).
   Affected packages: nginx-core:amd64

I believe that warning can be ignored.

Robie Basak (racb) wrote :

On IRC, Simon suggested this:

16:43 <sdeziel> teward: to add to possible solutions, using "listen [::]:80 default_server ipv6only=off;" alone seems to do the right thing no matter what is present, v4 only, v6 only or both

There's one known downside, which is that IPv4 connections are logged as IPv6 like this:

18:48 <teward> yes, but that makes the logs all log IPv6 addresses ::ffff:10.1.2.3 as an example

However as far as I understand that doesn't lose anything.

Opinions on this as a way of resolving this bug? Summary: we change the default listen directive to "listen [::]:80 default_server ipv6only=off;"

Feature freeze is on Thursday, so ideally we should make a decision on this very soon if we want any change to release in Focal.

T Jeske (t-jeske) wrote :

Will it log as ::ffff:10.1.2.3 if IPv6 is disabled on the system?

I could imagine this notation could confuse some tools for automatic analyses of logfiles. I fear that this would break something in the background without people even realizing it until it is too late. Imo failing hard should be the preferred option.

On Tue, Feb 25, 2020 at 01:41:42PM -0000, T Jeske wrote:
> Will it log as ::ffff:10.1.2.3 if IPv6 is disabled on the system?

I believe so, yes.

> I could imagine this notation could confuse some tools for automatic
> analyses of logfiles. I fear that this would break something in the
> background without people even realizing it until it is too late. Imo
> failing hard should be the preferred option.

I agree this isn't ideal. But ultimately, log file syntax does change
over time, tooling needs to be updated, and the time to make changes is
in new Ubuntu releases (rather than existing ones). So in principle I
think it's acceptable to make this change even though some log analysis
may fail until those analysers are updated.

However, it does seem quite late in the day to make this change for
Focal. It gives us less time to find tooling in the archive that may
need updating, and less time for the out-of-archive community to adjust,
too. Thomas has expressed the same opinion to me on IRC. So on that
basis, it looks like we'll be keeping the status quo for Focal, and
maybe changing it in Focal+1.

Andrew Gerald (co6aka) wrote :

Dan Streetman (ddstreet) wrote on 2020-02-21:
> For those coming here because their installation or upgrade of the 'nginx' package fails
> due to their system using ipv6.disabled=1, you need to edit the file...

FWIW, that doesn't work, and here I have all servers, including default servers, configured to listen only on IPv4 addresses. When "ipv6.disabled=1" is passed to the kernel, NGINX fails to start...period, even with no IPv6 servers configured. I also tried adding "ipv6=off" to the "resolver" directive, but that has no effect; IPv6 must be enabled on my server for NGINX to start.

Wilco Baan Hofman (wilco) wrote :

It is one thing to ipv6/conf/all/disabled=1, that is still supported. But ipv6.disable=1 should not be supported in any way. It is in direct conflict with modern software and proper deployments which should default to IPv6, in accordance with IETF BCP177.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.