28

I compiled the nginx on Ubuntu myself. I start my nginx with -c nginx.conf parameter. In my nginx.conf file, I try to turn off error log with but failed.

error_log /dev/null crit;

Still got the error message: nginx: [alert] could not open error log file: open() "/usr/nginx/logs/error.log" failed (2: No such file or directory)

How could I turn off this log or change its location?

Dean Chen
  • 3,800
  • 8
  • 45
  • 70
  • Have you tried removing the `error_log` declaration (your line)? :) – Sean3z Nov 14 '12 at 02:43
  • I tried just now, only use access_log, but still got the error message. I didn't create the folder:/home/dist/carrier/nginx/logs. Restarting nginx: nginx: [alert] could not open error log file: open() "/home/dist/carrier/nginx/logs/error.log" failed (2: No such file or directory – Dean Chen Nov 14 '12 at 07:23

6 Answers6

22

The syntax for disabling the error log is ok, but the docs state that a default logfile is used before the config is read. (which seems reasonable because how would it otherwise tell you you have an error in your config)

Try creating this file by hand with the correct permissions for the user that runs nginx. Or try starting the server as root.

RickyA
  • 15,465
  • 5
  • 71
  • 95
  • That's what I have done. use --prefix when compiling nginx to set the correct logs location and create the folder when installing my nginx service. – Dean Chen Nov 15 '12 at 11:51
  • `$ sudo chmod a+w /var/log/nginx/access.log /var/log/nginx/error.log` should help, but compiling nginx from source seems more viable solution. – Omar Al-Ithawi Jan 06 '14 at 11:59
  • Still unable to access it. I `chown`'d to `www-data:www-data` but that didn't help, either. Which user and group should the files belong to? – IIllIIll Nov 29 '15 at 12:46
  • 5
    The `chmod a+w` is a bad idea in almost all cases. Ensure that `error_log` is set at the *top level* of the nginx configuration (even outside the `http` block log). You will still get `nginx: [alert] could not open error log file: open() "/usr/nginx/logs/error.log"`, but `[alert]` is not a critical error and your server will start up anyway. Tried with nginx 1.4. – nh2 Jan 06 '16 at 19:07
17

I solved this issue using the -p parameter when starting nginx e.g:

/home/ubuntu/nginx/sbin/nginx -c /home/ubuntu/nginx/conf/nginx.conf -p /home/ubuntu/nginx

This will prepend any log paths specified in the config with the prefix directory.

Michael
  • 2,258
  • 1
  • 23
  • 31
  • 1
    Prefix solution works for me :) I've changed prefix directory to one that has write permission! Thanks! – zvjerka24 Dec 05 '13 at 14:32
  • 3
    You don't need to set `-p` to get it to work. But ensure that `error_log` is set at the *top level* of the nginx configuration. You will still get `nginx: [alert] could not open error log file: open() "/usr/nginx/logs/error.log"`, but `[alert]` is not a critical error and your server will start up anyway. Tried with nginx 1.4. – nh2 Jan 06 '16 at 19:08
  • Looks like `-p` option doesn't fully work in older versions; in 1.12.2. (Or, it's perhaps based on differences regarding @Randall's answer) ------ P.S. @nh2: Perhaps `[alert]` is not critical, but it strikes me as bad practice to get into a habit of ignoring such things, and thus it would be ideal to have a way to not ever emit it. (1.12.2, at least, does that.) – lindes Jan 08 '18 at 01:41
  • 1
    @lindes Oh yes sure. A clean solution is better. The less `[alert]` you have appear, the less you have to read to debug stuff. – nh2 Jan 08 '18 at 17:36
4

I just solved this by using this configure parameter:

./configure --prefix="$HOME/nginx" --error-log-path=/dev/stderr

Since I never use this nginx as a daemon and always run it in a shell, it makes sense for it to log errors to stderr.

Hubro
  • 56,214
  • 69
  • 228
  • 381
1

You can't solve the problem by specifying a -p prefix; because that would only apply to the directives in the configuration file; and as RickyA already noted the problem is that there is a compiled-in error log that nginx wants to open even before it opens the configuration. Changing permissions of the compiled-in error log is not ideal, for obvious reasons.

A workaround is to specify the error log as a configuration on the command line:

$ nginx -p . -g 'error_log error.log;'

or

$ nginx -p . -g 'error_log stderr;'

You'll still get an [alert] but at least it allowed me to start nginx as non-root on Ubuntu.

Ben Hekster
  • 11
  • 1
  • This also works/is necessary to properly run `nginx -t` as non-root (without recompiling). Without doing something like `nginx -t -g 'error_log stderr;'` the test will always fail without root. – wickedchicken Feb 26 '20 at 21:04
0

Per this post on the nginx.org mailing list (extract quoted below), the %%ERROR_LOG_PATH%% is set as a compile option, and checked immediately on startup, causing the "Could not open" alert. Specifying the prefix (with -p) may help suppress the alert, but only if the %%ERROR_LOG_PATH%% was specified as a relative path at compile time.

You can check how it is specified in your current executable with

nginx -V 2>&1 | grep -oE 'error-log-path=\S*'

That is why the solution proposed by @Michael works for some, but not for others.

See changelog:

Changes with nginx 0.7.53

...

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

*) Feature: now the start up errors and warnings are outputted to an error_log and stderr.

...

Now compiled in error_log value always used to log errors at start time (and emits warning if nginx can't open it). Once config file have been read - error_log from config will be used instead.

If you have compiled nginx with error_log path relative to prefix - it should be possible to override startup error_log via -p switch.

Maxim Dounin

Randall
  • 2,859
  • 1
  • 21
  • 24
-1

There's no need to use a command line parameter. Simply ensure you add the error_log directive to the very top of nginx.conf or at least before any error messages may occur.

nh2's comment from Jan 2016 suggests that this option would have been available for at least a couple years now. I can confirm it works and it's less hassle. Customisation to nginx.conf is less likely to cause issues with updates to a packaged nginx installation than the alternatives.

Sam Hall
  • 164
  • 1
  • 6