Opened 8 years ago

Last modified 6 days ago

#147 assigned defect

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 (12)

comment:1 by Maxim Dounin, 8 years ago

It's intentional behaviour introduce by Igor in 0.7.53:

    *) Change: now a log set by --error-log-path is created from the very
       start-up.

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.

comment:2 by maxim, 7 years ago

Owner: changed from somebody to sb
sensitive: 0
Status: newassigned

comment:3 by maxim, 7 years ago

Owner: sb removed

comment:4 by Maxim Dounin, 2 years ago

See also #1462.

comment:5 by Ruslan Ermilov, 20 months ago

See also #1583.

comment:6 by Maxim Dounin, 19 months ago

See also #1592.

comment:7 by cezmunsta@…, 12 months 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.

in reply to:  7 comment:8 by Maxim Dounin, 12 months 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.

comment:9 by cezmunsta@…, 12 months 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

in reply to:  9 ; comment:10 by Maxim Dounin, 12 months 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.

in reply to:  10 comment:11 by cezmunsta@…, 12 months 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

comment:12 by Maxim Dounin, 6 days ago

See also #1933.

Note: See TracTickets for help on using tickets.