Opened 7 years ago
Last modified 2 years ago
#1353 new enhancement
http and stream on the same "listen" should conflict
| Reported by: | 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 (4)
follow-up: 2 comment:1 by , 7 years ago
comment:2 by , 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 relatively rare to justify introducing such a mechanism.
comment:3 by , 3 years ago
| Type: | defect → enhancement |
|---|
As per the explanation above, reclassified as enhancement.
have a look at this:
https://forum.nginx.org/read.php?2,263177,263180#msg-263180