Opened 7 years ago

Last modified 7 years ago

#1353 new defect

http and stream on the same "listen" should conflict

Reported by: chipitsine@… Owned by:
Priority: minor Milestone:
Component: other Version: 1.13.x
Keywords: Cc:
uname -a: # uname -a
Linux nginx-bug 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: # nginx -V
nginx version: nginx/1.13.3
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie'

Description

here's sample config

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {

    default_type  application/octet-stream;
    access_log  off;

        server {
                listen       80;
                server_name  localhost;

                location / {
                        return 200;
                }

        }

}

stream {

        server {
                listen  80;
                proxy_pass  127.0.0.1:8080;
        }


}

it does not fail on "nginx -t"

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
#

however, nginx refuses to start

# nginx
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

I think, it would be nice to catch that error during "nginx -t" run

Change History (2)

in reply to:  1 comment:2 by Maxim Dounin, 7 years ago

Replying to RocFang@…:

have a look at this:

​https://forum.nginx.org/read.php?2,263177,263180#msg-263180

No, this is unrelated Linux-specific problem (Linux doesn't allow listening on a wildcard address and on an IP at the same time, while normal OSes do).

The problem Ilya talks about is different: nginx does not do early checks for listening conflicts between different top-level modules. That is, nginx is able to detect when you try to use conflicting addresses in different servers in stream:

$ cat nginx.conf
events {}
stream {
    server { listen 9000; return 1; }
    server { listen 9000; return 2; }
}
$ nginx -t
nginx: [emerg] duplicate "9000" address and port pair in /path/to/nginx.conf:4
nginx: configuration file /path/to/nginx.conf test failed

But it won't be able to tell the same socket is used in both stream and http:

$ cat nginx.conf
events {}
stream {
    server { listen 9000; return 1; }
}
http {
    server { listen 9000; }
}
$ nginx -t
nginx: the configuration file /path/to/nginx.conf syntax is ok
nginx: configuration file /path/to/nginx.conf test is successful

This problem is perfectly valid, though unlikely to be fixed, as this is not a bug, but rather lack of a mechanism to detect such configuration errors during configuration parsing, and such errors seem to be to be relatively rare to justify introducing such a mechanism.

Note: See TracTickets for help on using tickets.