Opened 4 years ago

Closed 4 years ago

#884 closed defect (duplicate)

NGINX 1.8.1 fails to restart depending on configuration set PIDFILE

Reported by: ketheriel@… Owned by:
Priority: major Milestone:
Component: nginx-core Version: 1.8.x
Keywords: Cc:
uname -a: Linux honeypot.local 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.8.1
built by gcc 4.8.3 20140911 (Red Hat 4.8.3-9) (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 --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-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-ipv6 --with-http_spdy_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'


Dear all,

The official RPM (Enterprise Linux 7) for NGINX provides a systemd file with the following configuration:

Description=nginx - high performance web server

ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID


On many of my systems I do have the following configuration:

[root@honeypot nginx]# cat nginx.conf
user nginx nginx;
worker_processes 3;
pid /var/run/;
error_log /var/log/nginx/error.log;

Since I specify /var/run/ as the pid file (which historically is pretty much where all redhat integrated software is) is breaks NGINX as soon as I upgrade.

The service fails to start properly (actually starts and serves information, but eventually systemd will timeout and nginx process goes down again).

Is it really necessary that the systemd unit file has PID instructions? I mean this sounds a bit lame and brings problems.

Could you guys please fix this? Either by removing PIDFile stuff from the unit file or fix the code so that it validates and or either exit with error or use the pid file defined in nginx.conf and ignore the systemd crap.

This was a dreadful thing to identify/diagnose.

Thanks in advance....

Nelson Marques

Change History (5)

comment:1 by thresh, 4 years ago

nginx 1.8.1 package for EL7 ships with /var/run/ in the nginx.conf and /run/ in the service file, and it works just fine because it's actually the same path:

# ls -ld /var/run
lrwxrwxrwx. 1 root root 6 Jun 19 2015 /var/run -> ../run
# rpm -qf /var/run
# rpm -V filesystem

Can you elaborate on "systemd will timeout and nginx process goes down again"? Any output from systemctl status nginx?

comment:2 by Ilyas Bakirov, 4 years ago

Common headache with systemd and daemons, and the best solution IMHO is to configure identical PID file location in systemd nginx.service and nginx.conf.

comment:3 by billygout@…, 4 years ago

I'm not sure if this is the same issue, but I noticed that: on a system that has /var/run as a symlink to /run, during a nginx reload, if the old conf had pidfile as /run/ and the new one has /var/run/, nginx will unlink the file /run/ after writing to the new /var/run/, and since these files happen to be the same by virtue of the symlink, the result is the absence of pidfile.

I would suggest to solve this, nginx should only delete the old pid file, if it can determine that the old and new pid are not simply aliases of each other. By running stat(2) on the two paths and inspecting the st_ino and st_dev fields, it should be possible to detect that really the two files are the same, the the deletion of the old pidfile should be skipped.


comment:4 by billygout@…, 4 years ago

AFAIU, this issue would be taken care of by this code, if merged:

comment:5 by Maxim Dounin, 4 years ago

Resolution: duplicate
Status: newclosed

As the original reporter's problem seems to be about changed pid in nginx configuration, closing this ticket as duplicate of #796.

Note: See TracTickets for help on using tickets.