我自己在Ubuntu上编译了nginx。 我用-c nginx.conf参数启动我的nginx。 在我的nginx.conf文件中，我尝试关闭错误日志但失败了。
error_log /dev/null crit;
仍然收到错误消息： nginx：[alert]无法打开错误日志文件：open（）“/ usr / nginx / logs / error.log”失败（2：没有这样的文件或目录）
如何关闭此日志或更改其位置？
答案 0 :(得分：17)
禁用错误日志的语法是正确的，但docs表示在读取配置之前使用默认日志文件。 （这似乎是合理的，因为它会如何告诉你配置中有错误）
尝试使用运行nginx的用户的正确权限手动创建此文件。或者尝试以root身份启动服务器。
答案 1 :(得分：15)
我在启动nginx时使用-p参数解决了这个问题，例如：
/home/ubuntu/nginx/sbin/nginx -c /home/ubuntu/nginx/conf/nginx.conf -p /home/ubuntu/nginx
这将在配置中指定的前缀目录前面添加任何日志路径。
答案 2 :(得分：0)
您无法通过指定-p前缀来解决问题;因为那只适用于配置文件中的指令;并且正如RickyA已经注意到的问题是，即使在打开配置之前，nginx也希望打开一个编译错误日志。由于显而易见的原因，更改编译错误日志的权限并不理想。
解决方法是在命令行上将错误日志指定为配置：
$ nginx -p . -g 'error_log error.log;'
或
$ nginx -p . -g 'error_log stderr;'
你仍然会得到[警告]，但至少它允许我在Ubuntu上以非root身份启动nginx。
答案 3 :(得分：0)
Per this post on the nginx.org mailing list（下面引用的摘录），%%ERROR_LOG_PATH%%被设置为编译选项，并在启动时立即检查，导致“无法打开”警报。指定前缀（使用-p）可能有助于抑制警报，但如果在编译时将%%ERROR_LOG_PATH%%指定为相对路径，则仅。
您可以使用
检查当前可执行文件中的指定方式 nginx -V 2>&1 | grep -oE 'error-log-path=\S*'
这就是为什么@Michael提出的解决方案适用于某些人，但不适用于其他解决方案。
请参阅changelog：
使用nginx 0.7.53进行更改
...
*）更改：现在创建一个由--error-log-path设置的日志 启动。
*）功能：现在将启动错误和警告输出到 error_log和stderr。
...
现在编译为error_log值，始终用于记录启动时的错误 时间（如果nginx无法打开它，则发出警告）。一旦配置文件 已被阅读 - 将使用来自config的error_log。
如果你已经使用相对于前缀的error_log路径编译了nginx - 应该可以通过-p覆盖启动error_log 开关。
Maxim Dounin
答案 4 :(得分：0)
无需使用命令行参数。只需确保将error_log指令添加到nginx.conf的最顶层，或者至少在发生任何错误消息之前。
从2016年1月起，nh2的评论表明，此选项至少可以使用几年。我可以确认它有效并且不那么麻烦。自定义nginx.conf不太可能导致更新打包的nginx安装问题而不是替代方案。