Fatal编程技术网
  • linux/
  • Linux Nginx仍然尝试打开默认错误日志文件，即使我在重新加载时设置了Nginx配置文件

Linux Nginx仍然尝试打开默认错误日志文件，即使我在重新加载时设置了Nginx配置文件

linux nginx

Linux Nginx仍然尝试打开默认错误日志文件，即使我在重新加载时设置了Nginx配置文件,linux,nginx,config,Linux,Nginx,Config,下面是我的nginx配置文件，位于/etc/nginx/nginx.conf 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;

下面是我的nginx配置文件，位于
/etc/nginx/nginx.conf

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
解决权限错误，但这里的主要问题是nginx试图打开一个错误日志文件（
/var/log/nginx/error.log
）

为什么它尝试访问另一个错误日志文件？

检查目录/home/Foo/log/nginx/上的权限。它必须可由nginx写入。按如下方式设置权限：

sudo chmod 766 /home/Foo/log/nginx
这是旧的。。。但我也经历了同样的痛苦，这是我的解决办法

正如您所看到的，日志是一个警报，而不是阻塞错误：

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只是喜欢在启动时检查该文件。我将nginx安装目录复制到另一个地方，启动它，新nginx的pid仍然在旧地方。因此，我建议您删除旧目录。

或者使用sudo重新加载nginx

sudo nginx-s reload

您可能需要使用
sudo

sudo nginx -t
这个简单的答案就是使用sudo

所以当我使用
sudonginx-t

一切都很好

顺便说一句，当我在Ubuntu18.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
该警报来自nginx初始化过程，当它检查是否可以写入已使用
--error log path
configure标志编译的错误日志路径时。这发生在nginx查看您的配置文件之前，所以您在其中写入什么并不重要

最近（2020-11-19），nginx中添加了一个
-e
选项，允许您覆盖在中编译的错误日志路径。您可以使用该选项将nginx指向用户可写文件（或者可能是
stderr
）

请参见

我在问为什么
Nginx
尝试访问另一个错误日志文件不是权限问题。即使存在许可问题。我认为在配置文件（
/home/Foo/log/nginx
）中设置的文件上显示的错误不是
/var/log/nginx/error.log
。nginx试图在读取将日志放在其他位置的指令之前打开默认错误日志，而用户Foo没有访问该位置的权限。这就是你得到第一个警报的原因。此外，目录/home/Foo/run/似乎不可写或不存在。为什么不使用默认位置呢？你到底想做什么？如果你想要一个真实的答案。。。向下滚动！这是不正确的，当nginx配置为使用非特权目录进行错误日志并作为非root用户运行时，这不会阻止nginx发出“警报”。此警报没有影响，nginx仍然启动并返回错误代码0，但不幸的是，它也发出此警报。对我来说也不起作用。错误是相同的
nginx:[警报]无法打开错误日志文件：open（）“/var/log/nginx/error.log”失败（2：没有这样的文件或目录）
。my env是一个具有非root用户的docker容器这似乎是正确的答案。这只是一个警告，nginx仍然启动并返回一个错误代码0。似乎没有办法阻止此“警报”。
nginx-t
导致了错误，而
sudo nginx-t
没有，但是如果此命令显示日志文件属于www数据，为什么我需要
sudo
ls-lah/var/log/nginx/error.log
（输出：
-rw-r-----1 www-data www-data…
）从中我看到我的组没有“写”访问权限，但我仍然不知道该做什么，特别是因为我最近设置的另一个几乎相同的服务器似乎从来没有出现过这个问题。这是否回答了你的问题？感谢您确认nginx只是不关心非根场景，他们最近修复了这个问题。如果您只是在测试系统上使用旧的nginx，而不想麻烦构建自定义版本：您只需替换二进制
bbe-e中的路径，/var/log/nginx/error.log，/tmp/log\u nginx\u error.log，/usr/sbin/nginx>/usr/sbin/nginx.hacked
，然后添加-x权限并继续使用/usr/sbin/nginx.hacked进行测试