Linux – Logrotate postrotate: Log file name variable empty

linuxlogrotate

According to the logrotate manual (https://manpages.debian.org/jessie/logrotate/logrotate.8.en.html), logrotate should invoke a script and hand over the filename of the rotated file as the first parameter of the script with this configuration:

/var/log/piwik/*.log {
    missingok
    postrotate
            /root/createStats.sh > /dev/null
    endscript
}

The createStats.sh script exists just for test purposes:

#!/bin/bash
echo "L: $1"
FNAME=/my.log
D=$(date)
echo "M $D ; $0 ; $1 ; $2" >> $FNAME

Unfortunately, my /my.log file does not contain any values for $1 (or $2):

M Tue 26 Dec 05:16:38 CET 2017 ; /root/createStats.sh ;  ;
M Tue 26 Dec 05:16:38 CET 2017 ; /root/createStats.sh ;  ;

I might be missing something. Does anyone have an idea?

My logrotate version is 3.8.7.

Best Answer

Think of postrotate as the script. You have to pass $1 around within it. Try

/var/log/piwik/*.log {
    missingok
    postrotate
            /root/createStats.sh $1 > /dev/null
    endscript
}

Related Solutions

Logrotate Issue – Original File Size Restored After Rotation

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.

Linux – Logrotation – postrotate firing too soon

Have you tried this:

/var/log/nginx/*.log {
        daily
        missingok
        rotate 90
        dateext
        compress
        **delaycompress**
        notifempty
        create 644 root adm
        sharedscripts
        postrotate
                [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
                /usr/local/bin/synclogs.sh
        endscript }

Take a look at the delaycompress option, of course without "*" HTH

Best Answer

Related Solutions

Logrotate Issue – Original File Size Restored After Rotation

Linux – Logrotation – postrotate firing too soon

Related Topic