Opened 7 years ago
Closed 7 years ago
#1365 closed defect (wontfix)
Pecular behaviour of nginx reload
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.13.x |
| Keywords: | Cc: | ||
| uname -a: | Linux delta.tgtedata.com 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/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
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.
The purpose of
nginx -s reloadis to send a signal to the running master process. It was introduced mainly for Windows, where you can't simply writekill -HUP `cat /path/to/nginx.pid`. The only reason whynginx -s reloadparses 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 thepiddirective 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, usuallyservice nginx reload.Note well that configuration testing as done by
nginx -tmight 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.