Can't Restart NginX Due to Socket Permissions

[vaultwiki@…]

I use unix sockets to proxy_pass requests to another server block for authentication. The current configuration works for my purposes. However, when restarting NginX, and always when rebooting the server, NginX is not able to start again because the sockets still exist and/or have different permissions than NginX has. I'm not aware of a way to tell NginX what user/group/permissions to give the sockets it creates.

My server blocks look like this:

user webuser webuser

...

http {

	...

	server {

		listen 80;
		server_name mydomain.com;

		location / {

			proxy_pass http://unix:/home/nginx/.auth/socket:;
			proxy_set_header Host mydomain.com;
			proxy_set_header X-Forwarded-For $remote_addr;
		}
	}

	server {
		listen unix:/home/nginx/.auth/socket;

		...
	}
}

Even though nginx runs as webuser, it requires a more privileged user, such as root, to start it. From my understanding, this is a more secure way to handle it than having webuser able to start and stop nginx directly.

In this case, upon starting, nginx automatically creates /home/nginx/.auth/socket with root:root 0666. And things run normally. Then we tell nginx to stop. However, either nginx doesn't clean the sockets up now, or it no longer has the necessary root:root permission to do so. Subsequently, when nginx starts, it tries to create /home/nginx/.auth/socket, but it already exists. Thus, nginx fails to start.

I am able to start nginx successfully again after I manually remove the troublesome socket from the file system using a more privileged user.

[Maxim Dounin]

Looks like duplicate of #753.

As a workaround, try the following:

• use ​configuration reload (HUP signal) instead of restarting nginx;
• if you want to stop nginx, use TERM/INT signal (fast shutdown) instead of QUIT (graceful shutdown).

[vaultwiki@…]

Thank you for the information. It pointed me in the appropriate direction: modified my systemd files to use TERM instead of QUIT, and restart now works as expected. At the next Linux kernel update, I will see if this resolves the problem during system reboot as well.