Logrotate reads everything about the log files it should be handling from a series of configuration files. The configuration files are normally kept in ~/cfg and log files in ~/logs. First, we need to create a configuration file for logrotate. Let us have this configuration file in /home/swayam/cfg/logrotate.conf. The contents of this configuration file look like this:

daily
rotate 1
create
compress
include /home/swayam/cfg/logrotate.d

Here, ‘daily’ tells logrotate to rotate log files every day; ‘rotate 1’ tells the logrotate to rotate the log files once before removing the old copies; ‘create’ tells the logrotate to create a new log file as soon as it rotates the old copy; ‘compress’ tells the logrotate to compress old logs when they are rotated. And finally, ‘include /home/swayam/cfg/logrotate.d’ instructs the logrotate to look for more instructions in ~cfg/logrotate.d.

Let us consider another example here:

/var/log/error_messages {
rotate 5
weekly
postrotate
/sbin/killall -HUP syslogd
endscript
}

Here we are setting the rules to handle the error_messages available at /var/log location. These files will go through five weekly rotations before they are removed. After the log file has been rotated, the command ‘/sbin/killall –HUP syslogd’ will be executed.
Logrotate finds extensive use in rotating the log files (error logs and access logs) generated by a web server. Consider the following piece:

/var/log/httpd/access.log  /var/log/httpd/error.log {
rotate 5
mail myname@myhost.com
size=100k
postrotate
/sbin/killall -HUP httpd
endscript
}

Here the two specified log files (access.log and error.log) are rotated whenever their size grows over 100KB and the old files are mailed to myname@myhost.com after going through five rotations. Thus in this case, note that old files are not removed from the system.

When we set the rules in the configuration files, we can use wildcards. However, one needs to be careful while using the latter. If we specify *, logrotate will rotate all files, including the previously rotated ones.

Let us consider one service-specific configuration file. As mentioned earlier, such configuration files are available in the /etc/logrotate.d directory.

$ cat /etc/logrotate.d/httpd
The output of the above command is given below…
/var/log/httpd/*.log {
weekly
rotate 52
compress
missingok
notifempty
postrotate
/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null`
}

The wildcard character (*) used in the above example instructs the logrotate to rotate all files ending with .log in a specific directory /var/log/httpd. The various log files are rotated 52 times before being removed from the system. The old versions of log files are compressed using gzip in order to save the disk space. We can note from the above example that we have used ‘missingok’ in the configuration files – it says that if the log file is missing, go onto the next one without issuing an error message. ‘notifempty’ specifies that the log file will not be rotated if it is empty.
For a specific program ‘webapp’, let us create a file /home/swayam/cfg/logrotate.d/webapp and this file will instruct the logrotate on how to rotate webapp’s log files. Inside this file, we will have a section for each log file. Let us take a look at one of the log file – say, gen.log of the program webapp.

/home/swayam/logs/webapp/gen.log {
weekly
rotate 5
copytruncate
compress
notifyempty
missingok
}

It can be seen that this specific section consists of the location of the log file to be rotated and instructions on how to do the rotation – which are inside the curly brackets. Here, ‘weekly’ tells logrotate to rotate the logs weekly; ‘rotate 5’ tells logrotate to rotate the logs five times before removing the old logs; ‘copytruncate’ tells logrotate to copy and truncate the original log file in place instead of renaming it and creating a new log file; ‘notifempty’ tells logrotate not to rotate a log file if it is already empty; and ‘missingok’ tells logrotate not to issue an error if the log file is missing.