nginx.conf and nginx.pid users and permissions

问题:

I'm embarking on watching my NGINX error.log files at level: warn... probably a silly idea and will cause me to crash my server as I work out any bugs happening, but hey, we're nerds and this is why we're here.

I'm noticing a [warn] and an [emerg] pop up every time I restart my server, which shows:

[warn] 8041#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
[emerg] 8041#0: open() "/run/nginx.pid" failed (13: Permission denied)

The top of my nginx.conf file reads:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

Which to me, shows me a few things.

1. I'm running NGINX with the user: www-data.
2. The number of worker processes that are allowed is automatically adjusted.
3. my PID file/information is being stored in /run/nginx.pid.

The error tells me that NGINX doesn't have permission to access /run/nginx.pid, which led me to see the user permissions for said file.

sudo ls -la /run/nginx.pid

reveals:

-rw-r--r-- 1 root root 5 Jun 18 05:34 /run/nginx.pid

Then trying:

ps -ef | grep nginx

produces:

root      5914     1  0 05:34 ?        00:00:00 nginx: master process /u
www-data  5917  5914  0 05:34 ?        00:00:00 nginx: worker process

scratches head

Now, can somebody out there tell me why, or how the hell NGINX has managed to create the master process with root ownership, and now the worker processes are owned by www-data?

Or more to the point, anybody have some suggestions on what to do about this [emerg] error I'm getting?

My first thought is to just try and change the ownership of the /run/nginx.pid file and see how NGINX likes it, but I kind of feel that even if I do that manually this time, when I restart the server, I'll run into the same problem.

My second thought is maybe there is somewhere else that I define my worker process initiation within NGINX..

Thanks.

EDIT

The contents of the /etc/systemd/system/multi-user.target.wants/nginx.service file are:

[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=/usr/sbin/nginx -s quit

[Install]
WantedBy=multi-user.target

回答1:

I got the same error on my Centos 7 server today.

nginx.pid" failed (13: Permission denied)

For me, it turned out to be a problem with SELinux. I did the following to make it work again:

systemctl stop nginx
touch /var/run/nginx.pid
chcon -u system_u -t httpd_var_run_t nginx.pid
systemctl start nginx

running

ls -Z nginx.pid

should output

-rw-r--r--. root root system_u:object_r:httpd_var_run_t:s0 nginx.pid

回答2:

In my case I got a

    "/usr/local/var/run/nginx.pid" failed (13: Permission denied)

    bind() to 0.0.0.0:80 failed (48: Address already in use)

and the working solution was made up of these steps:

1. stop root process

   sudo nginx -s stop
   

2. check if process stopped

   ps aux | grep nginx
   

3. restart process

   sudo nginx -s reload
   

gave me the error

    nginx: [error] open() “/usr/local/var/run/nginx.pid” failed (2: No such file or directory)

probabil .pid was started with the wrong root user as I uncommented the line with path to .pid in /usr/local/etc/nginx/nginx.conf and then I commented it back again

4. to start nginx as a user and not root

   brew services start nginx
   

5. result at running command

   ps aux | grep nginx
   
   youruser 89212 0.0 0.0 4268280 644 s002  S+ 2:46PM 0:00.00 grep nginx
   youruser 89179 0.0 0.0 4302204 1776 ?? S 2:45PM 0:00.00 nginx: worker process  
   youruser 89178 0.0 0.0  4275372 4368 ?? S 2:45PM 0:00.01 nginx: master process /usr/local/opt/nginx/bin/nginx -g daemon off;
   

And as it can be seen, the nginx process started with the expected user and not as root and the conflict between processes was gone and I could access the PHP application local domain.