我自己在 Ubuntu 上编译了 nginx。我用 -c nginx.conf 参数启动我的 nginx。在我的 nginx.conf 文件中，我尝试关闭错误日志但失败了。
error_log /dev/null crit;
仍然得到错误信息： nginx: [alert] could not open error log file: open() "/usr/nginx/logs/error.log" failed (2: No such file or directory)
如何关闭此日志或更改其位置？
禁用错误日志的语法是可以的，但文档声明在读取配置之前使用默认日志文件。（这似乎是合理的，因为否则它会如何告诉您您的配置中有错误）
尝试使用运行 nginx 的用户的正确权限手动创建此文件。或者尝试以 root 身份启动服务器。
我在启动 nginx 时使用 -p 参数解决了这个问题，例如：
/home/ubuntu/nginx/sbin/nginx -c /home/ubuntu/nginx/conf/nginx.conf -p /home/ubuntu/nginx
这将在配置中指定的任何日志路径前面加上前缀目录。
我刚刚通过使用此配置参数解决了这个问题：
./configure --prefix="$HOME/nginx" --error-log-path=/dev/stderr
由于我从不将此 nginx 用作守护程序并始终在 shell 中运行它，因此将错误记录到 stderr 是有意义的。
你不能通过指定-p前缀来解决问题；因为这只适用于配置文件中的指令；正如 RickyA 已经注意到的那样，问题是 nginx 甚至在打开配置之前就想要打开一个编译错误日志。出于显而易见的原因，更改已编译错误日志的权限并不理想。
一种解决方法是将错误日志指定为命令行上的配置：
$ nginx -p . -g 'error_log error.log;'
或者
$ nginx -p . -g 'error_log stderr;'
您仍然会收到 [警报]，但至少它允许我在 Ubuntu 上以非 root 用户身份启动 nginx。
根据nginx.org 邮件列表上的这篇文章（下面引用的摘录），它%%ERROR_LOG_PATH%%被设置为编译选项，并在启动时立即检查，导致“无法打开”警报。指定前缀 (with -p) 可能有助于抑制警报，但前提是在编译时将%%ERROR_LOG_PATH%%指定为相对路径。
您可以检查它是如何在您当前的可执行文件中指定的
nginx -V 2>&1 | grep -oE 'error-log-path=\S*'
这就是为什么@Michael 提出的解决方案适用于某些人，但不适用于其他人。
请参阅更改日志：
nginx 0.7.53 的变化
...
*) 更改：现在由 --error-log-path 设置的日志是从一开始就创建的。
*) 功能：现在启动错误和警告输出到 error_log 和 stderr。
...
现在编译为 error_log 值，始终用于在启动时记录错误（如果 nginx 无法打开它，则会发出警告）。读取配置文件后 - 将使用配置中的 error_log。
如果您使用相对于前缀的 error_log 路径编译 nginx - 应该可以通过 -p 开关覆盖启动 error_log。
马克西姆·杜宁
无需使用命令行参数。只需确保将 error_log 指令添加到 nginx.conf 的最顶部或至少在可能出现任何错误消息之前添加。
nh2 从 2016 年 1 月开始的评论表明，这个选项至少可以使用几年了。我可以确认它有效并且不那么麻烦。与替代方案相比，对 nginx.conf 的自定义不太可能导致打包 nginx 安装的更新出现问题。