1

I run logrotate through cron with the script

[alex@leia ~]$ cat /etc/cron.daily/logrotate
#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf >/dev/null
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0

which, according to the syslog, should work:

Dec 14 03:21:01 leia run-parts(/etc/cron.daily)[3041]: starting logrotate
Dec 14 03:21:01 leia run-parts(/etc/cron.daily)[3063]: finished logrotate

I expect this to also run the following directive:

[alex@leia ~]$ cat /etc/logrotate.d/www-data_uwsgi_nginx
/home/www-data/*/logs/*/*log {
    rotate 5
    size 20M
    nocompress
    missingok
    postrotate
        touch /tmp/uwsgi-reload
        [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
    endscript
    sharedscripts
}

But! It does not rotate the logs under /home/www-data. Other logs get rotated. If I run logrotate manually with

[alex@leia ~]$ sudo logrotate /etc/logrotate.conf

it does rotate the logs in question.

I saw the related question where the problem was with SELinux, and attempted that solution but it did not help in my case.

Edit: On request, the contents of /etc/logrotate.conf:

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
    minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.
Community
  • 1
kqr
  • 91
  • 1
  • 8
  • Show the contents of /etc/logrotate.conf itself – wurtel Dec 15 '15 at 14:03
  • @wurtel Provided. – kqr Dec 15 '15 at 14:11
  • You have `weekly` and `minsize 20M` specified. That means that the logfile will at most be rotated weekly, and then only if the size exceeds 20MB. So if you run it manually today, it won't be rotated again until at least next week, and then only if the size is large enough. Are you sure that's not the issue here? – wurtel Dec 15 '15 at 14:15
  • I have `size 20M` specified, not `minsize` – so time intervals shouldn't matter for those files, should they? `daily` is specified in the `/etc/logrotate.d` file – does this not override the "general" settings in `/etc/logrotate.conf`? – kqr Dec 15 '15 at 14:34
  • I don't see `daily` in your /etc/logrotate.d/www-data_uwsgi_nginx file. So the `weekly` is not overridden. – wurtel Dec 15 '15 at 14:39
  • @wurtel But doesn't the `size` directive override any time interval specified by rotating as soon as the file exceeds the size? – kqr Dec 16 '15 at 09:55
  • You haven't explicitly stated that that is the case. But yes, if the size exceeds 20MB then the file should be rotated when logrotate is run. – wurtel Dec 16 '15 at 10:30
  • @wurtel Hence my question: why is it rotated if I run `sudo logrotate /etc/logrotate.conf` manually, but not when cron (apparently) runs the same thing? – kqr Dec 16 '15 at 10:34
  • Again, you haven't explicitly shown that the file size exceeded 20MB at time of the cron job. Maybe it grew to that size between the cron job and your manual invocation. – wurtel Dec 16 '15 at 10:43
  • @wurtel Oh, I see. I know it exceeded 20 MB at the time of the cron job because it exceeded 20 MB last I checked, the cron job has run since then, and it's still not rotated. :) – kqr Dec 16 '15 at 10:46

1 Answers1

2

I asked for help in #centos, and it appears SELinux was the problem. According to aureport -a SELinux denied the process running under the logrotate_t context access to files in the home directory, which had the user_home_t label – not really a big surprise once you know how SELinux works!

I decided to just relabel the directories for the log files (the trailing .* makes the modification recursive):

# semanage fcontext -a -t var_log_t "/home/www-data/.*/logs/.*"
# restorecon -r /home/www-data/*/logs

I picked the var_log_t label because it sorta-kinda makes sense and it happens to be one I know should work. I'd like to use a label that makes more sense but I don't know how to list working ones. It might be possible to create a new policy but that seemed overkill for my purposes.

I'll have to wait a couple of days and then see if it has worked, but I suspect it will!

Edit: it worked like a charm! I'm so happy now.

kqr
  • 91
  • 1
  • 8