3 Basic Commands and Simple Shell Scripts Once you have your first Red Hat Enterprise Linux rhel
Download 1.85 Mb. View original pdf
|
| Log rotation During regular system operation, lots of daemons are in use, and the system itself generates logs that are used for troubleshooting and system checks. Some services might allow us to define a log file to write to based on the date, but usually, the standard is to log to a file named like the daemon in the /var/log directory for example, /var/log/cron. Writing to the same file will cause the file to grow until the drive holding the logs is filled, which might not make sense as after awhile (sometimes, under company-defined policies, logs are no longer useful. The logrotate package provides a script with a cron entry that simplifies the log rotation process. It is configured via /etc/logrotate.conf and is executed on a daily basis, as shown here: Tools for Regular Operations 134 Figure 4.15 – Example listing of logs and rotated logs (using date extension) If we check the contents of the configuration file, we will see that it includes some file definitions either directly there or via drop-in files in the /etc/logrotate.d/ folder, which allows each program to drop its own requirements without it affecting others when packages are installed, removed, or updated. Why is this important Because—if you remember from some of the tips earlier in this chapter (while speaking about disk space)—if logrotate just deleted the files and created anew one, the actual disk space would not be freed, and the daemon writing to the log would continue to write to the file it was writing to (via the file handle. To overcome this, each definition file can define a post-rotation command. This signals the process of log rotation so that it can close and then reopen the files it uses for logging. Some programs might require a signal such as kill –SIGHUP PID or a special parameter on execution, such as chronyc cyclelogs. With these definitions, logrotate will be able to apply the configuration for each service and, at the same time, keep the service working in a sane state. The configuration can also include special directives, such as the following missingok • nocreate • copytruncate • notifempty Summary 135 You can find out more about them (and others) on the man page for logrotate.conf (yes—some packages also include a man page for the configuration files, so try checking man logrotate. conf to get the full details!). The remaining general configuration in the main file allows us to define some common directives, such as how many days of logs to keep, if we want to use the date in the file extension for the rotated log files, if we want to use compression on the rotated logs, how frequently we want to have the rotation executed, and so on. Let’s look at some examples. The following example will rotate on a daily basis, keep 30 rotated logs, compress them, and use an extension with date as part of its trailing filename: rotate daily compress dateext In this example, it will keep 4 logs rotated on a weekly basis (so 4 weeks) and will compress the logs, but use a sequence number for each rotated log (this means that each time a rotation happens, the sequence number is increased for the previously rotated logs too): rotate weekly compress One of the advantages of this approach (not using dateext) is that the log naming convention is predictable as we have daemon.log as the current one, daemon.1.log as the prior one, and soon. This makes it easier to script log parsing and processing. Summary In this chapter, we learned about systemd and how it takes care of booting the required system services in an optimized way. We also learned how to check a service’s status, how to enable, disable, start, and stop it, and how to make the system boot into the different targets that we boot our system into. Time synchronization was introduced as a must-have feature, and it ensures our service functions properly. It also allows us to determine the status of our system clock and how to act as a clock server for our network. We also used system tools to monitor resource usage, learned how to check the logs that are created by our system to find out about the functional status of the different tools, and how we can ensure that logs are maintained properly so that older entries are discarded when they are no longer relevant. In the next chapter, we will dive into securing the system with different users, groups, and permissions. |