Opened 4 years ago
Closed 4 years ago
Last modified 4 years ago
#1740 closed enhancement (invalid)
ngins -s reopen / SIGUSR1 and permissions problem
|Reported by:||Owned by:|
|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 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/nginx.pid --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 http://nginx.org/en/docs/control.html , Nginx master process re-opens web.page-access/errors.log, 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/web.site-access.log" failed (13: Permission denied)
It's the same problem with logrotate and manual restarts:
# nginx -s reopen
# kill -USR1
From what I found here - http://mailman.nginx.org/pipermail/nginx/2011-January/024444.html - 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/nginx.pid" 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 , 4 years ago
|Status:||new → closed|
comment:2 by , 4 years 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: https://stackoverflow.com/questions/57201759/cant-make-nginx-reopen-log-files-by-using-nginx-s-reopen-or-kill-usr1-ngin
I find 0770 very permissive. Is it really the way to make 'nginx -s reopen' or 'kill -USR1' work?
comment:3 by , 4 years 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 , 4 years 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 , 4 years 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.
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.