Description of problem: Due to an incorrect signal specification, nginx continues to log to the rotated logfile. --signal=USR1 should be changed to --signal=SIGUSR1 Additionally, the nginx documentation states that, if logging configuration directives contain variables, the log directory should be writeable by the child process uid (nginx on Fedora). Ideally /var/log/nginx and the files within should be owned by nginx. This will require the addition of: create 0644 nginx or similar to /etc/logrotate.d/nginx. There might also be a case for creation of a nginx_log_t SELinux fcontext type to be applied to /var/log/nginx and its contained files. Version-Release number of selected component (if applicable): nginx-1.2.6-1 How reproducible: Every time Steps to Reproduce: 1. Install and configure nginx 2. Access some web content to create a non-zero length logfile 3. Wait for log rotation 4. Access some more web content 5. Observe that logging continues to the rotated logfile not the newly created one Actual results: Logging continues to the rotated logfile Expected results: With a correctly configured systemctl kill --signal=SIGUSR1 nginx.service logging after rotation performs as expected. Additional info: nginx log handling requires review and overhaul.
I couldn't replicate your issues with USR1 and SIGUSR1. Both seem to work the same for me. Also Lennart's blog post [1] suggests that HUP and be used in place of SIGHUP so I don't think it matters much. However, SIGUSR1 is indeed the correct name for the signal, so it's probably best to change it to that anyway to avoid confusion. Please let us know if this fixes your issue. I do agree that "create 0644 nginx root" should be added to the logrotate configuration. Builds to follow shortly...
nginx-1.2.6-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/nginx-1.2.6-2.fc18
nginx-1.0.15-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/nginx-1.0.15-7.fc17
Hi Jamie, Thanks for the swift action. I haven't seen Lennart's blog post on this subject but the systemctl manpage has this to say: --signal=, -s When used with kill, choose which signal to send to selected processes. Must be one of the well known signal specifiers such as SIGTERM, SIGINT or SIGSTOP. If omitted defaults to SIGTERM. I am following fc18 updates-testing so should pick-up the new package soon and will report back my findings ASAP. Regards, Neil Darlow
Package nginx-1.2.6-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nginx-1.2.6-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20553/nginx-1.2.6-2.fc18 then log in and leave karma (feedback).
With regards to the /var/log/nginx directory being owned by the nginx user, that should not be allowed. I originally had /var/log/nginx owned by the nginx user, and I changed it to be owned by root based on feedback from Alexander Peslyak (http://en.wikipedia.org/wiki/Solar_Designer). See the changelog. * Mon Feb 15 2010 Jeremy Hinegardner <jeremy at hinegardner dot org> - 0.6.39-4 - change directory ownership of log dir to root:root There is an issue with nginx and log rotation that I do not know if it has been resolved or not. Nginx opens the log files before it gives up root. This means that if the log directory is owned by nginx user then there is the possibility for a symlink attack. So, if you do not want a symlink attack to possibly take place then you have to leave them owned by root. The other side is that when the sigusr1 is sent to reopen the log files, the nginx process is now running as the nginx user, and it does not have the permissions to open the files since they are owned by root. I decided to stay on the secure side of things. I have not kept up to speed on the changes in nginx with respect to the log file opening and its security that is going on. I would say, the only way you should change the /ver/log/nginx directory to be owned by nginx is if: 1) nginx opens the log files AFTER giving up root permissions 2) the log files can now be opened with some sort of umask so you can have a common group between root and nginx 3) nginx has been changed to make sure that the log files are owned by it and are not symlinks to other files. -jeremy
Just to mention that in the package builds I uploaded today, the /var/log/nginx directory is still root:root owned.
Hi Jamie, I noticed that logfiles are set by: create 0644 root nginx This means that they will be readable by nginx but not writeable. Would a solution be? 1) create 0664 root nginx 2) Use SELinux policy to only permit nginx rw access to /var/log/nginx/*log
Hi, With the new update, things are still broken. The situation is: 1) A new logfile /var/log/nginx/access.log is created 2) The existing logfile is rotated as /var/log/access.log-20121219 3) The rotated logfile is not compressed 4) An e-mail is received with content: Subject: Anacron job 'cron.daily' on aspire.darlow.co.uk /etc/cron.daily/logrotate: Failed to issue method call: Access denied error: error running shared postrotate script for '/var/log/nginx/*log '
Hi Neil, I can't seem to replicate your issues. - using fresh f18, updates-testing enabled, selinux enabled - using fresh install of nginx-1.2.6-2 - systemctl start nginx.service - echo hello >> /var/log/nginx/access.log - echo hello >> /var/log/nginx/error.log - logrotate -f /etc/logrotate.conf - ls -l: nginx:nginx access.log root:root access.log.20121219.gz nginx:nginx error.log root:root error.log.20121219.gz No errors for me. Similar story on f17. I will change logrotate script to "create 0644 nginx nginx" as that seems more correct, although I don't think that in itself will change anything. The master process (which runs as root) changes the ownership of the log files anyway. Unfortunately, I'm not sure how to replicate your issue.
Hi Jamie, I found that when I run logrotate manually, as root, it works. Does /etc/logrotate.d/nginx execute as non-root or perform its file manipulations as the uid and gid specified in create? I think there is a difference between manual invocation and cron invocation. Regards, Neil Darlow
AFAIK, cron runs as root, and therefore should run logrotate as root. Have a look at the comments here: http://ask.metafilter.com/117371/Logrotate-cronjob-fails-but-running-at-commandline-works Do any of the other files in your /etc/logrotate.d/ folder have a missing "endscript" line or otherwise unterminated script?
nginx-1.2.6-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/nginx-1.2.6-3.fc18
nginx-1.0.15-8.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/nginx-1.0.15-8.fc17
(In reply to comment #12) > AFAIK, cron runs as root, and therefore should run logrotate as root. > > Have a look at the comments here: > http://ask.metafilter.com/117371/Logrotate-cronjob-fails-but-running-at- > commandline-works > > Do any of the other files in your /etc/logrotate.d/ folder have a missing > "endscript" line or otherwise unterminated script? No but there is a clue in the Anacron mail. I did a Google on: "Failed to issue method call: Access denied" and all results indicate that is was output from systemctl. So, for some reason the systemctl kill command is failing which would be consistent with what I am seeing with logging still occurring to the rotated file. This, in turn, implies that nginx did not receive the SIGUSR1. Coincidentally, executing: systemctl kill --signal=SIGUSR1 nginx.service as non-root causes exactly that error to be output. So, going up the chain we have: systemctl --> logrotate --> cron.daily --> run-parts --> anacron --> cron Any thoughts on whether any of these could be triggering the failure?
On closer inspection, SELinux policy needs to be amended: https://bugzilla.redhat.com/show_bug.cgi?id=889151
nginx-1.0.15-8.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
nginx-1.2.6-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.