Nginx master process running as root, but warnings state that it is not

Question

I am running nginx 1.11.3, compiled from source with the addition of the ngx_cache_purge module, on Ubuntu 14.04.3 server.

I'm seeing in the nginx error.log the following:

2016/08/03 14:30:00 [warn] 21827#21827: the "user" directive makes sense only if the master
  process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1

2016/08/03 14:30:00 [emerg] 15611#15611: BIO_new_file("/etc/letsencrypt/live/example.com/fullchain.pem") failed
  (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/example.com/fullchain.pem','r')
  error:2006D002:BIO routines:BIO_new_file:system lib)

The two lines always come in one after the other. The odd thing is that the site seems to be served properly, and https also seems to be working, despite it claiming in that error there (I think) that it can't read the certificate chain.

In nginx.conf, I have the first line set to user www-data www-data;

If I do ps aux | grep nginx, I see that the master process IS running as root, and the worker and cache processes as www-data – as it should be. I'm starting nginx by running sudo service nginx start.

Permissions on /etc/letsencrypt/live/example.com/ look like this:

ls -lah /etc/letsencrypt/live/example.com/
total 24K
drwxr-xr-x. 2 root root   93 Jan 20  2022 .
drwxr-xr-x. 3 root root   27 Nov  9  2021 ..
-rw-r--r--. 1 root root 3.7K Dec 27 00:03 ca.pem
-rw-r--r--. 1 root root 2.1K Dec 27 00:03 cert.pem
-rw-r--r--. 1 root root 2.2K Nov  9  2021 chain.pem
-rw-r--r--. 1 root root 5.8K Dec 27 00:03 fullchain.pem
-rw-r--r--. 1 root root 3.2K Dec 27 00:03 privkey.pem

nginx -V output in case it is useful:

nginx version: nginx/1.11.3
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
built with OpenSSL 1.0.2h  3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-module=/opt/nginx_cachepurge_module/ngx_cache_purge --add-dynamic-module=debian/extra/njs-0.1.0/nginx --with-threads --with-stream --with-stream_ssl_module --with-stream_geoip_module=dynamic --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'

Answer 1

I figured this out. For some of its https negotiation -- I think only the first https negotiation of each server block after nginx starts up -- nginx spins up a temporary root-user process that is then immediately closed as soon as the negotiation. For me, this was failing because I compiled nginx myself after previously having the repository version installed. Though I removed the standard version with apt-get remove before installing my own compiled nginx, some part of the original's startup script was left behind, and when my new nginx was trying to spin up that process (and it seems only that process, no other part), it was failing. I solved by doing a complete apt-get remove --purge and then reinstalling my compiled version.

Answer 2

In my case it was amplify agent periodically performing nginx -t as a non-root user causing a record in error.log.

This behaviour can be turned off by disabling Enable periodic "nginx -t" in Settings > Agent on amplify webpage.

Answer 3

You should make your private keys readable by ssl-cert group. Try

sudo chown -R root:ssl-cert /etc/letsencrypt/live/XXXXXXX.com/