即使我在重新加载时设置了 nginx 配置文件,Nginx 仍然尝试打开默认错误日志文件
Posted
技术标签:
【中文标题】即使我在重新加载时设置了 nginx 配置文件,Nginx 仍然尝试打开默认错误日志文件【英文标题】:Nginx still try to open default error log file even though I set nginx config file while reloading 【发布时间】:2016-03-19 10:52:47 【问题描述】:下面是我位于/etc/nginx/nginx.conf
的nginx配置文件
user Foo;
worker_processes 1;
error_log /home/Foo/log/nginx/error.log;
pid /home/Foo/run/nginx.pid;
events
worker_connections 1024;
use epoll;
http
access_log /home/Foo/log/nginx/access.log;
server
listen 80;
location = /
proxy_pass http://192.168.0.16:9999;
如您所见,我将日志、pid 文件位置更改为主目录。
当我重新启动Linux
时,它似乎工作了,Nginx
在我设置的文件和 pid 文件中记录了错误日志。
但是,当它尝试nginx -s reload
或其他时,它会尝试打开其他错误日志文件。
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2015/12/14 11:23:54 [warn] 3356#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
2015/12/14 11:23:54 [emerg] 3356#0: open() "/home/Foo/run/nginx.pid" failed (13: Permission denied)
nginx: configuration file /etc/nginx/nginx.conf test failed
我知道,我可以用sudo
解决权限错误,但这里的主要问题是错误日志文件(/var/log/nginx/error.log
) Nginx 试图打开。
为什么它会尝试访问另一个错误日志文件?
【问题讨论】:
这能回答你的问题吗? Nginx: Permission denied for nginx on Ubuntu 【参考方案1】:警报来自 nginx 初始化过程,当它检查是否可以写入已使用 --error-log-path
配置标志编译的错误日志路径时。这发生在 nginx 甚至查看你的配置文件之前,所以你在里面写什么并不重要。
最近(2020-11-19),一个-e
选项被添加到 nginx,允许您覆盖已编译的错误日志路径。您可以使用该选项将 nginx 指向用户可写文件(或者可能是stderr
)。
见https://trac.nginx.org/nginx/changeset/f18db38a9826a9239feea43c95515bac4e343c59/nginx
【讨论】:
感谢您确认 nginx 只是不关心非 root 场景并且他们最近修复了。如果您只是在测试系统上使用旧 nginx 并且不想费心构建自定义版本:您可以替换二进制文件中的路径bbe -e 's,/var/log/nginx/error.log,/tmp/log_nginx_error.log,' /usr/sbin/nginx > /usr/sbin/nginx.hacked
,然后添加 -x 权限并继续使用 /usr/sbin/nginx.hacked测试
最佳答案,谢谢 :)【参考方案2】:
这个简单的答案是使用 sudo。
所以当我使用sudo nginx -t
时
一切都很好。
顺便说一句,当我在 Ubuntu 18.04 上增加 php.INI 中的文件上传限制时,这对我产生了错误,并且我重新启动了我的 PHP 和我的 NGINX,这就是我测试的时候:
2020/10/19 20:27:43 [warn] 1317#1317: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2020/10/19 20:27:43 [emerg] 1317#1317: BIO_new_file("/etc/letsencrypt/live/websitename.com/fullchain.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/websitename.com/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
【讨论】:
【参考方案3】:您可能需要使用sudo
触发它
sudo nginx -t
【讨论】:
nginx -t
导致错误,sudo nginx -t
没有,但是如果此命令显示日志文件归 www-data 所有,为什么我需要 sudo
? ls -lah /var/log/nginx/error.log
(输出:-rw-r----- 1 www-data www-data ...
)
来自unix.stackexchange.com/a/184005/48973 我看到我的组没有“写”访问权限,但我仍然对该怎么做感到困惑,特别是因为我最近设置的另一台几乎相同的服务器从来没有好像有这个问题。【参考方案4】:
或者使用 sudo 重新加载 nginx
sudo nginx -s reload
【讨论】:
【参考方案5】:是的,Nginx 只是喜欢在启动时检查该文件。我将nginx安装目录复制到另一个地方,我启动它,新Nginx的pid仍然在旧位置。所以我建议你删除旧目录。
【讨论】:
【参考方案6】:这是旧的......但我经历了同样的痛苦,这是我的解决方案。
如您所见,日志是警报,而不是阻塞错误:
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
这应该不是问题 :) Nginx 只是喜欢在启动时检查该文件...
只需使用-p
选项。像这样在本地启动 Nginx 对我有用:
nginx -c /etc/nginx/nginx.conf -g 'daemon off;' -p /home/Foo/log/nginx
【讨论】:
对我也不起作用。错误是相同的nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (2: No such file or directory)
。我的环境是一个非 root 用户的 docker 容器
这似乎是正确的答案。只是一个警告,nginx仍然启动并返回错误代码0。似乎没有办法阻止这种“警告”。【参考方案7】:
检查目录 /home/Foo/log/nginx/ 的权限。它必须是 nginx 可写的。像这样设置权限:
sudo chmod 766 /home/Foo/log/nginx
【讨论】:
我在问为什么Nginx
尝试访问另一个错误日志文件而不是权限问题。即使有权限问题。我认为错误显示我在配置文件中设置的文件错误(/home/Foo/log/nginx
)不是/var/log/nginx/error.log
。
nginx 在读取您的指令以将日志放在其他位置之前尝试打开默认错误日志,并且用户 Foo 没有访问该位置的权限。这就是您收到第一个警报的原因。此外,似乎目录 /home/Foo/run/ 不可写或不存在。为什么不只使用默认位置?你到底想做什么?
如果您想要真正的答案,请...向下滚动!
这是不正确的,这不会阻止 nginx 在配置为使用非特权目录来存储 error_log 并以非 root 用户身份运行时发出“警报”。警报没有影响,nginx 仍然启动并返回错误代码 0,但不幸的是它也发出了此警报。以上是关于即使我在重新加载时设置了 nginx 配置文件,Nginx 仍然尝试打开默认错误日志文件的主要内容,如果未能解决你的问题,请参考以下文章
Nginx常用命令(启动/重启/停止/测试配置文件/重新加载配置文件)