Opened 7 years ago

Closed 7 years ago

#1365 closed defect (wontfix)

Pecular behaviour of nginx reload

Reported by: gb12335@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.13.x
Keywords: Cc:
uname -a: Linux 3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.12.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-4) (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/ --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'


Good day colleagues,

I am writing the system for hosting management and faced with the necessity of checking nginx configuration. The issue is that I don't want to call nginx -t every time, because we know that if the configuration is broken and master process is working it won't just apply it.
So I decided to send the nginx -s reload command in case of configuration changes and change the return code.
Everything is fine: if the configuration is totally wrong (i.e. syntaxically incorrect) nginx -s reload return error code and I can handle it. But there is one case when I can't get the information that something went wrong. It is when the configuration file is syntaxically correct, but the listen directives contains IP addresses absent on the interface. In this case nginx -s reload returns 0 (because the config is OK and the signal is sent to the master process), but the configuration can't be apply. The nginx -t correctly handles this sutiation but I want to emphasize that there is no sense in spawning one another test process of nginx, because nginx -s reload makes the configuration test too. Let's save the CPU cycles and memory :-)

I checked the versions nginx/1.12.0, nginx/1.12.1 and nginx/1.13 on two distributions - Centos 7 and Ubuntu 14. All versions are affected.

I propose to change the behaviour of nginx -s reload that it will test if the bind can succeed and return the error in case of mismatch between IPs in config and on the interface.

Change History (1)

comment:1 by Maxim Dounin, 7 years ago

Resolution: wontfix
Status: newclosed

The purpose of nginx -s reload is to send a signal to the running master process. It was introduced mainly for Windows, where you can't simply write kill -HUP `cat /path/to/`. The only reason why nginx -s reload parses configuration is that it needs to know where nginx pidfile resides. It doesn't do configuration testing, only parsing (there is a difference). And it is not expected to do anything else - rather, we can consider using a specialized configuration parsing to only look for the pid directive instead of doing full configuration parsing.

On Unix systems you can completely avoid extra CPU cycles spent on configuration parsing by using kill -HUP ... instead. On most systems this is what naturally happens when you use system tools to reload nginx, usually service nginx reload.

Note well that configuration testing as done by nginx -t might not be sufficient for a correct configuration reload, and might even be wrong in some cases. Not to mention that it is itself a duplicate work, as master process will parse and apply configuration anyway. See #724 for additional details.

Note: See TracTickets for help on using tickets.