#147 closed defect (fixed)
nginx touched /var/log/nginx-error.log even when error_log are switched off
Reported by: | Mr Dandy | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-core | Version: | 1.0.x |
Keywords: | Cc: | ||
uname -a: | FreeBSD t.my.domain 9.0-RELEASE FreeBSD 9.0-RELEASE #2: Fri Jan 6 02:41:28 MSK 2012 root@t.my.domain:/usr/obj/usr/src/sys/GENERIC amd64 | ||
nginx -V: |
nginx version: nginx/1.1.18
TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-file-aio --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --add-module=/usr/ports/www/nginx-devel/work/agentzh-headers-more-nginx-module-3580526 --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_ssl_module --with-http_stub_status_module --with-pcre |
Description
Nginx create /var/log/nginx-error.log even when error_log switched off. nginx.conf:
error_log /dev/null;
events {
worker_connections 1024;
}
http {
error_log /dev/null;
access_log off;
server {
listen 80;
server_name localhost;
error_log /dev/null;
}
}
after:
% service nginx start
nginx-error.log in the /var/log directory created
Change History (16)
comment:1 by , 13 years ago
comment:2 by , 12 years ago
Owner: | changed from | to
---|---|
sensitive: | → 0 |
Status: | new → assigned |
comment:3 by , 12 years ago
Owner: | removed |
---|
follow-up: 8 comment:7 by , 6 years ago
It was done to make sure configuration parsing errors are logged somewhere, especially during unattended boot when stderr isn't normally logged anywhere
This does not make sure that errors are logged somewhere.
Running as a non-privileged user will error and will not log to file:
$ egrep -rn '^[[:space:]]{0,}((error|access)_log|http)' /etc/nginx /etc/nginx/nginx.conf:9:http { /etc/nginx/nginx.conf:17: access_log /var/log/custom/nginx-default-access.log main; /etc/nginx/nginx.conf:18: error_log /var/log/custom/nginx-default-error.log error; $ nginx -c /etc/nginx/nginx.conf -t nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied) nginx: the configuration file /etc/nginx/nginx.conf syntax is ok 2019/02/26 22:38:13 [emerg] 8299#8299: open() "/var/log/nginx/error.log" failed (13: Permission denied) nginx: configuration file /etc/nginx/nginx.conf test failed $ nginx -c /etc/nginx/nginx.conf -t -g 'error_log /var/log/custom/nginx-default-error.log error;' nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied) nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful $ logout # wc -l /var/log/nginx/error.log 0 /var/log/nginx/error.log
Note that forcing the global directive on the command line changes the status of the test from failed -> successful.
Please fix.
comment:8 by , 6 years ago
Replying to cezmunsta@…:
It was done to make sure configuration parsing errors are logged somewhere, especially during unattended boot when stderr isn't normally logged anywhere
This does not make sure that errors are logged somewhere.
Sure. In some cases this is simply impossible. Yet the code in question tries to do so in as many cases as possible. If it's not, nginx will show an alert to inform you about the problem, as clearly demonstrated by the terminal output you've provided.
follow-up: 10 comment:9 by , 6 years ago
Sure. In some cases this is simply impossible. Yet the code in question tries to do so in as many cases as possible. If it's not, nginx will show an alert to inform you about the problem, as clearly demonstrated by the terminal output you've provided.
Agreed, in some cases it is impossible, but even when forcing a global directive via the command line it still tries to use the default error log.. yet passes the test
follow-up: 11 comment:10 by , 6 years ago
Replying to cezmunsta@…:
Agreed, in some cases it is impossible, but even when forcing a global directive via the command line it still tries to use the default error log.. yet passes the test
That's because configuration directives as specified in the command line is simply an additional part of the configuration. And opening the default log happens before parsing the configuration. That is, from nginx point of view your example is not at all different from the example provided in the original report.
comment:11 by , 6 years ago
Replying to mdounin:
That's because configuration directives as specified in the command line is simply an additional part of the configuration. And opening the default log happens before parsing the configuration. That is, from nginx point of view your example is not at all different from the example provided in the original report.
When using containers, avoiding the use of root, sudo and suid are best practice so this particular issue forces the user to create a file and change its permissions even if they never want to use it.
It certainly does not seem to warrant an alert-level message when unable to log to file - the user doesn't need to attend to it immediately and in fact may never need to attend to it.
As this bug seems like it will never be fixed by just writing to stderr in such circumstances... perhaps it can at least have one of the following applied so that it can easily be ignored:
- change to
KERN_NOTICE
- add an
--error-log
option that can be used instead
It's intentional behaviour introduce by Igor in 0.7.53:
It was done to make sure configuration parsing errors are logged somewhere, especially during unattended boot when stderr isn't normally logged anywhere. The only way to avoid it as of now is to recompile nginx with --error-log-path=stderr.
While I don't consider this behaviour correct (and I actually tried to object at 0.7.53 times), it's highly unlikely to be changed due to Igor's position on this.