Nginx servers on both *:80 and <ip>:80? also duplicate listen parameters error when binding by just specific ips

[Francis Daly]

On Fri, Apr 29, 2016 at 05:12:44PM -0400, CJ Ess wrote:

Hi there,

> Where I get into problem is if I do something like this:
> 
>     server {
>         listen 127.0.0.1:8088 backlog=65536 deferred;
>         return 200 "listen 127.0.0.1:8088\n";
>     }
>     server {
>         listen 10.0.1.2:8088 backlog=65536 deferred;
>         return 200 "listen 10.0.1.2:8088\n";
>     }
>     server {
>         listen 8088;
>         return 200 "listen 8088\n";
>     }
> 
> In that case I get errors like "nginx: [emerg] bind() to 0.0.0.0:8088
> failed (98: Address already in use)". So the workaround is obviously not to
> use those options - I could patch the source to use a backlog larger then
> 511.

That is covered (not necessarily explicitly) at
http://nginx.org/r/listen. There's a section on "parameters specific to
socket-related system calls"; and the description of "bind" indicates
that it can be applied implicitly.

If your OS does not allow you to bind() to both IP:port and to
INADDR_ANY:8088, then the above config (which says to bind individually to
127.0.0.1:8088 and 10.0.1.2:8088 and 0.0.0.0:8088) is broken on your OS.

>      listen *:80 backlog=65536 deferred;
>      listen *:80 backlog=65536 deferred;
>      listen *:80  backlog=65536 deferred default_server;

> Then I get the error message "nginx: [emerg] duplicate listen options for
> 0.0.0.0:80 in /etc/nginx/nginx.conf".

"...only once for a given address:port pair".

>      listen *:80;
>      listen *:80;
>      listen *:80 backlog=65536 deferred default_server;

> From the ss -l output I am picking up the larger listen queue which I'm
> happy about, though its confusing why nginx is picking them from that last
> server stanza (it has the same behavior without the default_server
> keyword).

I think it's clear why it happens, when you know what system calls are
used in response to the config.

I'm not sure how the documentation could be enhanced for clarity without
becoming unwieldy.

> If I'm doing a virtual hosting type setup and I'm including all
> of my server definitions from individual files in a subdirectory, it
> appears that any one of them could bump up the backlog, but if any two
> server stanzas have options to do it then it causes an error.

There are lots of other things that could be put into the files that
would be invalid configurations too.

> Maybe the
> best way to do it is to have some sort of dummy entry that sets the options
> - if its always the last server stanza that sets the listen options then
> maybe include all the other server stanzas  and have the dummy at the end
> that sets the backlog and deferred options?

Once upon a time, only the default_server entry could set them (but
it wasn't called default_server then). Since that is a once-per-port
option too, perhaps you could make a policy of only setting them in
that server{}?

You'd still have the issue of multiple bind()s; but that is presumably
"change your config design or change your OS".

	f
-- 
Francis Daly        francis at daoine.org