Opened 8 years ago
Closed 8 years ago
#1040 closed defect (wontfix)
nginx start failed if upstream server domainname is not resolved
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.11.x |
| Keywords: | upstream server dns | Cc: | |
| uname -a: | 2.6.32-042stab112.15 #1 SMP Tue Oct 20 17:22:56 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.11.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (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-p ath=/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=/v ar/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/v ar/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 --add-dynamic-module=naxsi-0.55rc2/naxsi_src --with-http_ssl _module --with-http_realip_module --with-http_addition_module --with-http_sub_mo dule --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with -http_gunzip_module --with-http_gzip_static_module --with-http_random_index_modu le --with-http_secure_link_module --with-http_stub_status_module --with-http_aut h_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module =dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add- dynamic-module=njs-ef2b708510b1/nginx --add-dynamic-module=ngx_devel_kit-0.3.0rc 1 --add-dynamic-module=lua-nginx-module-0.10.2 --add-dynamic-module=headers-more -nginx-module-0.30rc1 --add-dynamic-module=nginx-upload-module-2.2 --add-dynamic -module=nginx-upload-progress-module-v0.9.0 --add-dynamic-module=naxsi-0.55rc2/n axsi_src --add-dynamic-module=nginx-push-stream-module-0.5.1 --add-dynamic-modul e=redis2-nginx-module-0.13 --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --w ith-ipv6 --with-http_v2_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_ SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=ge neric' |
||
Description
add to nginx config:
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080;
server unix:/tmp/backend3;
server backup1.example.com:8080 backup;
server backup2.example.com:8080 backup;
}
try nginx -t
nginx: [emerg] host not found in upstream "backend1.example.com" in /etc/nginx/vhosts.d/test.ru.conf:12
nginx: configuration file /etc/nginx/nginx.conf test failed
service nginx start
nginx not started
please change '[emerg] fatal error' to 'warning' message
and allow start nginx with this problem
I would also like to add the ability to periodically reresolv server domainnames in the upstream block
Change History (4)
comment:1 by , 8 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:2 by , 8 years ago
why nginx assumes the name written is incorrect ???
one problem with DNS resolver on nginx host, and nginx fail to start
this is very bad
i have N server in upstream, and fail to resolv one server name - this is not the reason to abort nginx.
N-1 server in upstream block ready to serving
comment:3 by , 8 years ago
| Resolution: | wontfix |
|---|---|
| Status: | closed → reopened |
comment:4 by , 8 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | reopened → closed |
Because in most cases this means just a typo, or a system-wide problem like non-working DNS. If you don't want nginx to depend on DNS - don't use domain names in nginx configuration, use IP addresses instead.
It is also more or less obvious that when you reload nginx configuration, you probably don't want to apply new configuration if most of the names there can't be resolved just because you've happened to try reload when your DNS server accidentally went down. Much better approach (and it's what is used by nginx) is to reject such a configuration and continue working with an old one, which used to work before.
The only case when accepting a configuration with non-resolvable names can somewhat help is initial startup, when there is no previous good configuration available. But even in this case rejecting a configuration is much more deterministic approach, as it allows to immediately detect and fix the problem, instead of starting a half-working service with problems, potentially non-detectable by any monitoring software.
The behaviour is exactly as designed. If a name fails to resolve during configuration parsing, nginx assumes the name written is incorrect and configuration parsing fails.
As for the ability to periodically re-resolve names in the upstream block, this feature is available in commercial subscription.