Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

After installing a new CentOS 6.0 server, logrotate was working absolutely fine. Then one day due to a kernel panic, the server had to be hard booted, and ever since log rotation is not rotating the logs.

So I did a separate cron entry to rotate logs manually and forcefully and redirected the output to a log file, and got the following lines for each file:

rotating pattern: /home/mail3/log/popMailProcessing.log  forced from command line (60 rotations)
empty log files are rotated, old logs are removed
considering log /home/mail3/log/popMailProcessing.log
error: stat of /home/mail3/log/popMailProcessing.log failed: Permission denied

However, if I do a logrotation manually from command line, it works flawlessly. The command I use on command line is:

logrotate -v -f /etc/logrotate.d/mail3-logs

My logrotate.conf file can be seen here.

The log rotation file which logrotate uses via cron job can be seen here.

My crontab entry is:

03 00 * * * root /usr/sbin/logrotate -f -v /etc/logrotate.d/mail3-logs &>> /var/log/logrotate/rotate.log

SELinux is enforcing, and it was enforcing prior to the hard boot too. The directory where the logs are kept have the root as their owner and directory has complete permissions.

Any clue what is causing the permission denied error?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Your original error messages make no sense with what you're showing for your cron that runs your logrotate.

rotating pattern: /home/mail3/log/popMailProcessing.log  forced from command line (60 rotations)
empty log files are rotated, old logs are removed
considering log /home//log/popMailProcessing.log
error: stat of /home/mail3/log/popMailProcessing.log failed: Permission denied

What are these paths doing going to /home/mail3/log/*? Also what's missing from the /home//log/popMailProcessing.log line? Seems like you're only showing some of the actual situation in your question.

Debugging the issue

Put this line in a shell script, logrotate.sh:

/usr/sbin/logrotate -f -v /etc/logrotate.d/mail3-logs &>> /var/log/logrotate/rotate.log

Make it executable and run it like this from the cron:

03 00 * * * root strace -s 2000 -o /tmp/strace.log /path/to/logrotate.bash

In going through the output you should see what is getting tripped up by the permissions problems.


After conversing with the OP he mentioned that the above debugging technique uncovered that SELinux was enabled. He was perplexed as to why this was the case since he had previously disabled it with the command setenforce 0.

Disabling SELinux in this fashion will only remain in this state until the next reboot. The default mode for SELinux is dictated by this file on Fedora/CentOS:

$ cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#   enforcing - SELinux security policy is enforced.
#   permissive - SELinux prints warnings instead of enforcing.
#   disabled - SELinux is fully disabled.
# SELINUXTYPE= type of policy in use. Possible values are:
#   targeted - Only targeted network daemons are protected.
#   strict - Full SELinux protection.

To permanently disable SELinux you'll want to change the line SELINUX=.. to one of the 3 states, enforcing, permissive, disabled.

I would encourage you however to take the time to understand why SELinux is disallowing the access to the directory these log files are within, and add the appropriate context's so that SELinux allows this access. SELinux is an important part of the layered security model that is facilitated on Linux distros that make use of it, and blindly disabling it is taking one of the critical layers away.


share|improve this answer
mail3 is an instance of a mail app. I have corrected the path. As of these errors are the only output I have been able to get out of the situation. If there is some more info that is needed, please tell me about it, I'll get it. –  Gautam Somani Mar 21 at 18:45
@GautamSomani - I would wrap the logrotate ... command in a shell script and run strace -s 2000 -o /tmp/strace.log logrotate.sh from cron to see what's having issues with the permissions. –  slm Mar 21 at 18:47
Yes, it was the selinux being enforced which caused the problem. Disabling it solved the prob. But how did a hardboot caused this problem when earlier too it was enforcing!? Any light on that? –  Gautam Somani Mar 22 at 11:20
@GautamSomani - how did you disable it? If you setenforce 0 this only hold for the current boot, a reboot will revert to whatever it was set to prior. There's another method if you need to make it disabled permanently. Rather then disable it though you should be able to find the context that needs to get added to the filesystem and just add them. –  slm Mar 22 at 12:00
I did use setenforce 0, and will set the context, but I still don't understand that why did the hardboot cause the selinux to deny the permission. Any clue about that? –  Gautam Somani Mar 22 at 14:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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