Opened 8 years ago

Closed 8 years ago

#1040 closed defect (wontfix)

nginx start failed if upstream server domainname is not resolved

Reported by: LuckySB@… 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/ --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'


add to nginx config:

upstream backend {
    server       weight=5;
    server unix:/tmp/backend3;

    server   backup;
    server   backup;

try nginx -t

nginx: [emerg] host not found in upstream "" in /etc/nginx/vhosts.d/
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 Maxim Dounin, 8 years ago

Resolution: wontfix
Status: newclosed

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.

comment:2 by LuckySB@…, 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 LuckySB@…, 8 years ago

Resolution: wontfix
Status: closedreopened

comment:4 by Maxim Dounin, 8 years ago

Resolution: wontfix
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.