#724 closed defect (wontfix)
Init script does not check config on reload for Ubuntu mainline packages
| Reported by: | Tom Duckering | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-package | Version: | 1.7.x |
| Keywords: | Cc: | ||
| uname -a: | Linux public-router-1.mgmt.perf-dmz 3.13.0-46-generic #75~precise1-Ubuntu SMP Wed Feb 11 19:21:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.7.10
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --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-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --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_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed' --with-ipv6 |
||
Description
We've just noticed that when reloading the config is not checked (as it is with restart). Code from /etc/init.d/nginx:
...
reload|force-reload)
log_daemon_msg "Reloading $DESC" "$NAME"
do_reload
log_end_msg $?
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
do_configtest -q || exit $RETVAL
do_stop
...
There seems to be precedence for doing this - as seen in a fix to the debian package (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539778)
This is seen in the 1.7.10-1 package taken from http://nginx.org/packages/mainline/ubuntu/
Package details:
> dpkg -s nginx Package: nginx Status: install ok installed Priority: optional Section: httpd Installed-Size: 1026 Maintainer: Sergey Budnevitch <sb@nginx.com> Architecture: amd64 Version: 1.7.10-1~precise Provides: httpd Depends: libc6 (>= 2.14), libpcre3 (>= 8.10), libssl1.0.0 (>= 1.0.1), zlib1g (>= 1:1.2.0), lsb-base, adduser Conffiles: /etc/logrotate.d/nginx db861faafc08f38fcce873913ba3459f /etc/nginx/conf.d/example_ssl.conf 84724f296c7056157d531d6b1215b507 /etc/nginx/conf.d/default.conf 4dce452bf8dbb01f278ec0ea9ba6cf40 /etc/nginx/scgi_params e9fd19c7d1f0cecbd46b3cb041ae19c7 /etc/nginx/win-utf 3749ffe19bedd842eb87e83d544e5ce6 /etc/nginx/fastcgi_params f597fb54a6fa1c9a9678dd3ae377d385 /etc/nginx/koi-utf 3e338aca6a53a5420fc791b5ef86f64c /etc/nginx/koi-win bfa0b80381fed2b1dfcf617b0ba204ec /etc/nginx/mime.types bd837e7b34f5c9b8d89957d0527f0d44 /etc/nginx/uwsgi_params 2aaaf1e3535752e74d2942db8b3632cb /etc/nginx/nginx.conf f7984934bd6cab883e1f33d5129834bb /etc/default/nginx e2b1ae0f31c6d03d3305ef526b0ba3b5 /etc/init.d/nginx 0525b92e368668d1dc07c2ee2e3df0a1 Description: high performance web server nginx [engine x] is an HTTP and reverse proxy server, as well as a mail proxy server.
Change History (6)
comment:1 by , 9 years ago
follow-up: 3 comment:2 by , 9 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Reload and configuration file testing are distinct things. All what reload is supposed to do is to send the HUP signal to nginx. In it's turn, running nginx master process will check the configuration, and if it's correct and can be applied - it will do so by starting new worker processes and gracefully shutting down old ones.
Doing a configuration test before a reload in init script is wrong for a number of reasons. In particular, it will do obviously incorrect things if you are doing a binary upgrade, and running nginx binary is not the same as one on disk. It will also waste CPU time duplicating work already done by nginx master process (and in some cases this time is significant, up to several minutes in my practice).
Note well that to check results of a reload you have to look into logs, and there is no other way to find out if a reload was successful or not. Even if configuration testing is successful, reloading nginx may still fail due to various reasons.
comment:3 by , 7 years ago
Replying to mdounin:
Note well that to check results of a reload you have to look into logs, and there is no other way to find out if a reload was successful or not. Even if configuration testing is successful, reloading nginx may still fail due to various reasons.
In a production environment, we use "error" level in error_log. So information about running workers not recorded in the log file. How can we know whether the reload was successful in this case?
comment:4 by , 7 years ago
Consider looking at PIDs of running worker processes, and their process titles. As long as reloading is successful, titles of old processes are expected to be changed to nginx: worker process is shutting down, and new worker processes will appear. More details can be found here.
Also - it wasn't clear where this init script code is coming from. We looked at the nginx repo on github but found nothing. Where we looking in the wrong place?