I was having trouble with supervisord being unable to start nginx on a new dev vm I had setup. In the supervisor stderr log for nginx and nginx’s error.log I was getting:
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/nginx-1.9.12/conf/nginx.conf ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)
Yet in my /etc/supervisor/conf.d/nginx.conf program file for supervisord, I had user=root. So it looked like supervisord was not trying to start nginx as the root user, ignoring the user line in its configuration file.
However, when I ran sudo /opt/nginx/sbin/nginx -t I was getting exactly the same error. So clearly it wasn’t a supervisord problem. But why was I getting error messages about the master process not running with super-user privileges, and it being unable to bind to port 80 when it was being run as root / sudo?
Eventually I figured it out – I had done a recursive chmod on the nginx directory setting both the suid and sgid bits. The owner of the nginx executable was www-data, and so it was always being executed as the www-data user due to the sticky bit.
Running sudo chmod -R "u-s" /opt/nginx/ removed the suid bit and allowed me to start nginx using supervisord successfully.
What I’d prefer to do is to set the sgid only on directories. But I’m using ansible to provision the machine and there is no way (other than a shell call) to easily perform a recursive chmod only on directories. So what I’ve done for the moment is to just change the mode to set the sticky bit for group only.
Likely no-one else bothers setting sgid or suid on program directories, and so this post won’t be helpful to anyone else. But just in case, or if I do the same thing again in the future, hopefully this will help you / me save some time and fix the problem quickly.