Got an email from my server about a failed Cron Job

@desiredpersona - Take a look at /etc/logrotate.d/nginx, does your file look like:

/var/log/nginx/*.log {
        weekly
        missingok
        rotate 52
        compress
        delaycompress
        notifempty
        create 0640 www-data adm
        sharedscripts
        prerotate
                if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
                        run-parts /etc/logrotate.d/httpd-prerotate; \
                fi \
        endscript
        postrotate
                invoke-rc.d nginx rotate >/dev/null 2>&1
        endscript
}

…if so, try swapping out:

invoke-rc.d nginx rotate >/dev/null 2>&1

…with:

nginx -s reload

If that doesn’t work, try swapping it out for:

service nginx rotate

I’ve seen reports that the invoke-rc.d..... line causes issues for others as well. It doesn’t seem to happen on Debian (I use Debian daily as a primary OS on most all personal, client and development deployments).

It would also be advisable to comment the compress line that you remove the comment from as, if your file contains the same command, compress is already defined as an option in the command, thus you shouldn’t need to define it elsewhere.

check logrotation configurations are correct logrotate -f -v /etc/logrotate.d/nginxdf -h

Manually run the logrotationlogrotate -f -v /etc/logrotate.d/nginx to check if it’s working. (failed for me)

in some cases it logrotation may fail due to incorrect ownership of logs.

for me ownership of /var/log/nginx/domain.access.log was www-data:root. we will need to change it using chown www-data:adm /var/log/nginx/*

running manually logrotate -f -v /etc/logrotate.d/nginx and this worked and logs rotated successfully.