Opened 5 years ago

Closed 5 years ago

Last modified 16 months ago

#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 (5)

comment:1 Changed 5 years ago by tom.duckering@…

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?

comment:2 follow-up: Changed 5 years ago by mdounin

  • Resolution set to wontfix
  • Status changed from new to 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 in reply to: ↑ 2 Changed 2 years ago by zasca@…

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 Changed 2 years ago by mdounin

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.

comment:5 Changed 16 months ago by mdounin

See also #1567.

Note: See TracTickets for help on using tickets.