In a Linux system, one of the most interesting (and reasonably one of the most important as well) directories is /var/log. As per Filesystem Hierarchy Standard, the activity of most services running in the system are written to a file inside this directory or one of its subdirectories.
Those files are known as logs and logs are the key to examine how the system is operating (and how it has behaved in the past). Logs are also the first source of data where administrators and engineers look while troubleshooting.
If we look at the contents of /var/log on a CentOS/RHEL/Fedora and Debian/Ubuntu (for a change) we will see the following log files and subdirectories.
Please note that the result may be slightly different in your case depending on the services running on your system(s) and the time they have been running.
In RHEL/CentOS and Fedora
# ls /var/log
In Debian and Ubuntu
# ls /var/log
In both cases, we can recognise that some of the log names end as expected in “log”, while others are either renamed using a date (for example, maillog-20160822 on CentOS) or compressed (consider auth.log.2.gz and mysql.log.1.gz on Debian)
This is not a default behaviour based on the selected distribution but can be modified at will using directives in the configuration files, as we will see in this article.
If logs were kept forever, they would finally end up filling the filesystem where /var/log resides. In order to stop that, the system administrator can use an excellent utility called logrotate to clean up the logs on a periodic basis.
In a few words, logrotate will rename or compress the main log when a condition is met (more about that in a minute) so that the next event is recorded on an empty file.
In addition, it will remove “old” log files and will keep the most current ones. Of course, we get to decide what “old” means and how often we require logrotate to clean up the logs for us.
Installing Logrotate in Linux
To install logrotate, just use your package manager:
---------- On Debian and Ubuntu ----------
# aptitude update && aptitude install logrotate
---------- On CentOS, RHEL and Fedora ----------
# yum update && yum install logrotate
It is worth and well to note that the configuration file (/etc/logrotate.conf) may symbolise that other, more specific settings may be placed on individual .conf files inside /etc/logrotate.d.
This will be the case if and only if the following line exists and is not commented out:
include /etc/logrotate.d
We will stick with this approach, as it will support us to keep things in order and use the Debian box for the following examples.
Configure Logrotate in Linux
Being very versatile tool, logrotate gives plenty of directives to assist us in configuring when and how the logs will be rotated, and what should happen right afterwards.
Let’s include the following contents in /etc/logrotate.d/apache2.conf (note that numerous likely you will have to create that file) and check each line to indicate its purpose:
/var/log/apache2/* {
weekly
rotate 3
size 10M
compress
delaycompress
}
The first line shows that the directives inside the block apply to all logs inside /var/log/apache2:
- Weekly means that the tool will try to rotate the logs on a weekly basis. Other possible values are daily and monthly.
- rotate 3 shows that only 3 rotated logs should be kept. Thus, the oldest file will be removed on the fourth subsequent run.
- size=10M sets the minimum size for the rotation to take place to 10M. In other words, each log will not be rotated until it touches 10MB.
- Compress and delayompress are used to tell that all rotated logs, except for the most recent one, should be compressed.
Let’s accomplish a dry-run to see what logrotate would do if it was actually executed now. Use the -d option followed by the configuration file (you can actually run logrotate by omitting this option):
# logrotate -d /etc/logrotate.d/apache2.conf
The results are shown below:
Instead of compressing the logs, we could rename them after the date when they were rotated. To do that, we will use the dateext directive. If our date format is other than the default yyyymmdd, we can specify it using dateformat.
Note that we can even stop the rotation from happening if the log is empty with notifempty. In addition, let’s tell logrotate to mail the rotated log to the system administrator (xyz@mydomain.com in this case) for his / her reference (this will want a mail server to be set up, which is out of the extent of this article). Note that we can even stop the rotation from happening if the log is empty with notifempty. In addition, let’s tell logrotate to mail the rotated log to the system administrator (xyz@mydomain.com in this case) for his / her reference (this will want a mail server to be set up, which is out of the extent of this article). Note that we can even stop the rotation from happening if the log is empty with notifempty. In addition, let’s tell logrotate to mail the rotated log to the system administrator (xyz@mydomain.com in this case) for his / her reference (this will want a mail server to be set up, which is out of the extent of this article).
If you require to get emails about logrotate, you can setup Postfix mail server as shown here: Install Postfix Mail Server
/var/log/squid/access.log {
monthly
create 0644 root root
rotate 5
size=1M
dateext
dateformat -%d%m%Y
notifempty
mail gabriel@mydomain.com
}
As shown in the image below, this log did not need to be rotated. However, when the size condition is met (size=1M), the rotated log will be renamed access.log-25082020 (if the log was rotated on August 25, 2020) and the main log (access.log) will be re-created with access permissions set to 0644 and with root as owner and group owner.
Finally, when the number of logs finally touches 6, the oldest log will be mailed to xyz@mydomain.com.
Now let’s assume you require to run a custom command when the rotation takes place. To do that, place the line with such command between the post-rotate and end script directive.
For example, let’s assume we require to send an email to root when any of the logs inside
/var/log/myservice gets rotated. Let’s add the lines in red to /etc/logrotate.d/squid.con
var/log/myservice/* {
monthly
create 0644 root root
rotate 5
size=1M
postrotate
echo "A rotation just took place." | mail root
endscript
}
>
Last but not least, it is essential to note that options present in /etc/logrotate.d/*.conf override those in the main configuration file in case of conflicts.
Logrotate and Cron
By default, the installation of logrotate produces a crontab file inside /etc/cron.daily named logrotate. As it is the case with the other crontab files inside this directory, it will be executed daily starting at 6:25 am if anacron is.
Otherwise, the execution will begin around 7:35 am. To check, watch for the line containing cron.daily in either /etc/crontab or /etc/anacrontab.
