Debugging logrotate postrotate script

amazon s3amazon-web-servicesdebugginglogrotate

Following is my logrotate conf.

/mnt/je/logs/apache/jesites/web/*.log" {
        missingok
        rotate 0
        size 5M
        copytruncate
        notifempty
        sharedscripts
        postrotate
                /home/bitnami/.conf/compress-and-upload.sh /mnt/je/logs/apache/jesites/web/ web 
        endscript
}

And compress-and-upload.sh script,

#!/bin/sh
# Perform Rotated Log File Compression
tar -czPf $1/log.gz $1/*.1

# Fetch the instance id from the instance
EC2_INSTANCE_ID="`wget -q -O - http://169.254.169.254/latest/meta-data/instance-id`"
if [ -z $EC2_INSTANCE_ID ]; then
echo "Error: Couldn't fetch Instance ID .. Exiting .."
exit;           
else    
        /usr/local/bin/s3cmd put $1/log.gz s3://xxxx/logs/$(date +%Y)/$(date +%m)/$(date +%d)/$2/$EC2_INSTANCE_ID-$(date +%H:%M:%S)-$2.gz
fi
# Removing Rotated Compressed Log File
rm -f $1/log.gz

The files are rotated, but shell script is not executed. I don't know how to debug the postscript.

Is there any logfile I chek to see if there is any permission issues.

If i directly execute the script from commandline file upload works.

Thanks.

Best Answer

logrotate usually runs as a cron job, and its errors end up being mailed to root. Have a look at /var/mail/root, or alternatively make sure that /etc/aliases directs root's mail somewhere sensible, and that your instance can in fact send mail.

Related Solutions

Logrotate: how to access the output file in postrotate

I'm not aware of any variables you can use if that's what you're looking for. However immediately after rotating the log, you should know precisely the name that the file has been rotated to based on the configuration you've set for the rotation (/var/log/somefile.1 or the like).

Perhaps it would be easier to answer if you described actual problem you're trying to solve?

Linux – Logrotate Successful, original file goes back to original size

This is probably because even though you truncate the file, the process writing to the file will continue writing at whichever offset it were at last. So what's happening is that logrotate truncates the file, size is zero, process writes to the file again, continuing at the offset it left off, and you now have a file with NULL-bytes up to the point where you truncated it plus the new entries written to the log.

od -c after truncate + sudden growth, generated output along the lines of:

0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
33255657600  \0   C   K   B   -   s   e   r   v   e   r       [   h   t   t
33255657620 <more log output>

What this says is from offset 0 to 33255657600 your file consists of null bytes, and then some legible data. Getting to this state doesn't take the same amount of time it would take to actually write all those null-bytes. The ext{2,3,4} filesystems support something called sparse files, so if you seek past a region of a file that doesn't contain anything, that region will be assumed to contain null-bytes and won't take up space on disk. Those null bytes won't actually be written, just assumed to be there, hence the time it takes to go to 0 to 3.5GB don't take a lot of time to. (You can test the amount of time it takes by doing something like dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1, this should generate a file of over 3GB in a few milliseconds).

If you run ls -ls on your logfiles after they've been truncated and had a sudden growth again, it should now report a number at the beginning of the line which represents the actual size (in blocks occupied on disk), which probably is orders of magnitude smaller than the size reported by just ls -l.

Related Topic