Opened 17 months ago

Closed 17 months ago

Last modified 13 months ago

#1740 closed enhancement (invalid)

ngins -s reopen / SIGUSR1 and permissions problem

Reported by: seem8@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.14.x
Keywords: Cc:
uname -a: Linux [hostname] 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx -V
nginx version: nginx/1.14.0 (Ubuntu)
built with OpenSSL 1.1.0g 2 Nov 2017
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-FIJPpj/nginx-1.14.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/ --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module


Since this is my first bug report, hello everyone.

I have a minor problem with SIGUSR1 and it's totally on my side, but I think it's pretty common configuration.

I changed permissions to nginx logs, so www-data (default Ubuntu user for Nginx) will not able to read, nor write them, not even change directory to them. This creates a problem in with logrotate, because Nginx stops logging every midnight.

According to this , Nginx master process re-opens, gracefully restart workers and then tell them to use a new one. It creates log files with www-data read/write permissions, which I try to avoid, but even then the workers are not able to reach them. From the /var/log/nginx/error.log:

2019/03/07 09:01:07 [emerg] 25817#25817: open() "/dir/with/logs/" failed (13: Permission denied)

It's the same problem with logrotate and manual restarts:
# nginx -s reopen
# kill -USR1 cat /var/run/

From what I found here - - functions responsible for that are in /src/os/unix/ngx_process_cycle.c file.

My only solution is to change "kill -USR1 cat /var/run/" to "systemctl reload nginx", because then it's logging fine, but there is a risk of misconfiguration that will prevent Nginx from reloading.

Thanks in advance.

Change History (5)

comment:1 by Maxim Dounin, 17 months ago

Resolution: invalid
Status: newclosed

For nginx worker processes to be able to open log files in /dir/with/logs/, all directories must be at least searchable by nginx user. The behaviour you've observed suggests they are not, and "not even change directory to them" in your text indicate the same. You have to fix this for things to work.

comment:2 by adriano-di-giovanni@…, 13 months ago

I have the same problem and I solved by doing as follows:

usermod -a -G adm www-data
chown -R www-data:adm /var/log/nginx
chmod -R 0770 /var/log/nginx

as I posted in this SO question:

I find 0770 very permissive. Is it really the way to make 'nginx -s reopen' or 'kill -USR1' work?


comment:3 by Maxim Dounin, 13 months ago

For log rotation to work, nginx worker processes need to be able to open logs specified in the configuration for writing. Certainly 0770 on log directory is not something required, nor www-data as the owner of the directory.

Note well that using www-data as the owner of the directory might result in privilege escalation being possible in your setup - see CVE-2016-1247 about similar issue in Debian packages in the past.

comment:4 by adriano-di-giovanni@…, 13 months ago

Thanks for your reply. Do you suggest to use root as the owner?
I understand that 0770 is not required but it seems to be the only value that makes things work in my setup. Any ideas?


comment:5 by Maxim Dounin, 13 months ago

Usual approach is to use root-owned log directory, and pre-create new log files during log rotation, writable by nginx workers.

If you have further questions, consider using support options available.

Note: See TracTickets for help on using tickets.