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

[Mr Dandy]

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

[Maxim Dounin]

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.

[Maxim Dounin]

See also #1462.

[Ruslan Ermilov]

See also #1583.

[Maxim Dounin]

See also #1592.

[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.

[Maxim Dounin]

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.

[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

[Maxim Dounin]

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.

[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

[Maxim Dounin]

See also #1933.