Description of problem: When starting the nginx service via systemd using the provided unit file, the log files created in /var/log/nginx are owned by root:root, even though the log directory is owned by nginx:nginx (mode: 700). However, the default logrotate config (/etc/logrotate.d/nginx) that comes with the nginx package creates log files as nginx:nginx and then sends a signal to nginx's process to reopen the logs as the nginx user like so: postrotate /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true endscript Therefore, the ownership of the /var/log/nginx directory cannot be changed to a user other than nginx or else logrotate will fail to reopen the logs as the nginx user, and show this in the error.log: ... [emerg] 31850#0: open() "/var/log/nginx/error.log" failed (13: Permission denied) ... [emerg] 31850#0: open() "/var/log/nginx/access.log" failed (13: Permission denied) The service will still work fine if you just started it with systemctl since the logs are then opened as root. At best, both systemctl and logrotate should create and open the log files with the same ownership and same user. Version-Release number of selected component (if applicable): Tested with nginx-1.12.2-2.el7.x86_64, but did not validate with previous versions. How reproducible: Very easily. Steps to Reproduce: 1. Install the epel/x86_64 yum repository 2. Install nginx package 3. Check ownership of /var/log/nginx (should be mode 700/nginx:nginx) 4. Execute: systemctl start nginx 5. Check ownership of log files in /var/log/nginx (should be mode 644/root:root) 6. Execute: curl -I http://localhost at least once 7. Confirm it works. Should get a response and the access.log file should contain lines confirming your access. 8. Change the ownership of the /var/log/nginx directory to a user other than nginx (could be any) 9. Execute: systemctl restart nginx 10. Run steps 6-7 again, and confirm it still works 11. Force a log rotation: logrorate -f /etc/logrotate.d/nginx -v 12. Check the log files in /var/log/nginx. You should see new log files owned by nginx:nginx, and the error.log file should contain the lines mentioned in the description confirming the nginx user is unable to open the files. 13. Execute the curl commands again and confirm it still works, but no logs are created anymore. 14. Change the ownership of /var/log/nginx back to the nginx user 15. Force a log rotation again and confirm that it was able to (new error.log file should be empty and if you execute curl again you should see entries in acess.log) Actual results: (See above) Expected results: (See above) Additional info: N/A
Correction, step 11 of reproduction steps should read: Force a log rotation: logrotate -f /etc/logrotate.d/nginx -v
I'll fix this in the next release.
FEDORA-2021-10c1cd4cba has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-10c1cd4cba
FEDORA-2021-1556d440ba has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1556d440ba
FEDORA-2021-3aa9ac7fd1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3aa9ac7fd1
FEDORA-2021-1556d440ba has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-1556d440ba` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1556d440ba See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-10c1cd4cba has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-10c1cd4cba` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-10c1cd4cba See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-3aa9ac7fd1 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3aa9ac7fd1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3aa9ac7fd1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-10c1cd4cba has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-1556d440ba has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-3aa9ac7fd1 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.