Linux – How to use wildcards within logrotate configuration files

man logrotate

   dateformat format_string
          Specify  the  extension for dateext using the notation similar to strftime(3) function. Only %Y %m
          %d and %s specifiers are allowed.  The default value is -%Y%m%d. Note that also the character sep‐
          arating log name from the extension is part of the dateformat string. The system clock must be set
          past Sep 9th 2001 for %s to work correctly.  Note that the datestamps  generated  by  this  format
          must be lexically sortable (i.e., first the year, then the month then the day. e.g., 2001/12/01 is
          ok, but 01/12/2001 is not, since 01/11/2002 would sort lower while it is later).  This is  because
          when using the rotate option, logrotate sorts all rotated filenames to find out which logfiles are
          older and should be removed.

Can anyone please tell me if "dateext" is correct? I want the log filename to be something like "access.log-2010-12-04".

Insert a dateformat directive to your configuration file, something like this:

 /usr/local/nginx/logs/*.log {
    daily
    dateext
    dateformat -%Y-%m-%d
    ...

One more thing: Can I do the log rotation every day on a specific time (e.g. 11 pm)?

By default, logrotate is running via cron at 4 A.M:

/etc/cron.daily/logrotate

#!/bin/sh

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

You can move this file to somewhere and rename to logrotate.sh, then create a new file in /etc/cron.d/ as belows:

0 23 * * * root /path/to/logrotate.sh

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.