Opened 8 years ago

Last modified 8 months ago

#147 assigned defect

nginx touched /var/log/nginx-error.log even when error_log are switched off

Reported by: subbsd@… 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 (11)

comment:1 Changed 7 years ago by mdounin

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 Changed 7 years ago by maxim

  • Owner changed from somebody to sb
  • sensitive set to 0
  • Status changed from new to assigned

comment:3 Changed 7 years ago by maxim

  • Owner sb deleted

comment:4 Changed 21 months ago by mdounin

See also #1462.

comment:5 Changed 16 months ago by ru

See also #1583.

comment:6 Changed 15 months ago by mdounin

See also #1592.

comment:7 follow-up: Changed 8 months ago by 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.

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 in reply to: ↑ 7 Changed 8 months ago by mdounin

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 follow-up: Changed 8 months ago by cezmunsta@…

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

comment:10 in reply to: ↑ 9 ; follow-up: Changed 8 months ago by mdounin

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 in reply to: ↑ 10 Changed 8 months ago by cezmunsta@…

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
Note: See TracTickets for help on using tickets.