2

I am using CentOS, NGINX and Passenger to serve a Rails application. I have SELinux activated, and have had a series of problems with logrotate. I have been able to resolve most of the issues by following various advice online. Unfortunately, logrotate is not successfully rotating my NGINX logfiles. NGINX is installed in /opt/nginx

This is my logrotate config file:

/opt/nginx/logs/*log {
daily
rotate 30
missingok
notifempty
sharedscripts
delaycompress
postrotate
[ ! -f /opt/nginx/logs/nginx.pid ] || kill -USR1 `cat /opt/nginx/logs/nginx.pid`
endscript
}

These are the messages I am receiving in /var/log/messages

Mar  9 03:49:14 localhost setroubleshoot: SELinux is preventing /usr/sbin/logrotate from rename access on the file logrotate_temp.RTg4y3. For complete SELinux messages. run sealert -l 8c5238cd-3e95-4af6-b150-498080c862b8
Mar  9 03:49:14 localhost setroubleshoot: SELinux is preventing /usr/sbin/logrotate from rename access on the file logrotate_temp.OjvGsG. For complete SELinux messages. run sealert -l 8c5238cd-3e95-4af6-b150-498080c862b8
Mar 10 03:55:46 localhost logrotate: ALERT exited abnormally with [1]

I have tried using sealert to update the policies as the messages recommend, however this does not resolve the issue (I suspect that this maybe because the temp files always have different names).

Can anyone suggest how I can resolve this so the logfiles get successfully rotated.

-- EDIT -- added output of

sudo sealert -l 8c5238cd-3e95-4af6-b150-498080c862b8

:

SELinux is preventing /usr/sbin/logrotate from rename access on the file logrotate_temp.NuwGkX.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that logrotate should be allowed rename access on the logrotate_temp.NuwGkX file by  default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep logrotate /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
  • Post sealert -l 8c5238cd-3e95-4af6-b150-498080c862b8 output. – Xavier Lucas Mar 10 '15 at 14:31
  • 1
    HI Xavier. I have added detail as suggested. – niciliketo Mar 11 '15 at 9:16
  • I am still having an issue with this. When I try logrotate manually logrotate -vf /etc/logratate.d/nginx it works correctly, however it still fails on the scheduled run. – niciliketo Mar 18 '15 at 9:09
2

I found that the problem lay with a couple of the older (rotated) log files.

running ls --scontext in the directory where the log lives showed that 2 of the rotated logs did not have the var_log_t context.

I fixed this by deleting these particular files (they were several months old).

On the next scheduled run, the logs rotated correctly.

0

Could it have something to with with the fact that you are not declaring permissions for the Logrotate control file with something like this. (note the create 0644.... line)

/var/log/nginx/*log {
     create 0644 nginx nginx
     daily
     rotate 10
     missingok
     notifempty
     compress
     sharedscripts
     postrotate
         /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
     endscript }
  • Thanks Sean. I tried declaring permissions. In my case I dont have an nginx user, so made it root instead. Unfortunately, I still see the errors and the file doesnt get rotated. – niciliketo Mar 11 '15 at 9:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.