Logrotate - Not Just for the System

I've seen a few threads about logrotate. Two thread types I've noticed are:

1. Persons not understanding logrotate and how to use it
2. Persons not happy with logrotate and it's normal means of operation - mainly because they'd like to use it for something other than the system log files.

My intentions here are to cover the second case however I will start describing a bit about logrotate and how to use it. So those who are new to logrotate and seeking some guidance, the general overview section will give you some information.

General Overview of Logrotate

Logrotate(8) is a system command which allows you to cause rotation, compression, and mailing of your log files to accomplish clearing of large log files and backup of those log files so that you have your required records.

This all makes sense; however one needs to consider that log files may or may not get very large depending on what data gets put into them.

The concept of "large" is a matter of opinion especially with disk arrays capable of holding data in the multi-terabyte range.

There are other reasons for log rotation which may make it useful for an administrator:

1. Having time-bound backup files covering a range of dates so as to make searching more efficient for when one has to look back at a specific day or time to find an event.
2. Keeping the size of the textual log file manage-able. Even though a few tens or hundreds of Megabyte sized text file is not a "storage space" problem, given the the log files are text, several hundred Megabytes of text all in one file makes for an extremely lengthy file for viewing or editing.

Log rotation has defaults, and typically a default installation of logrotate will put in place a default rotation configuration file. You can modify this file as well as create your own, using the various keywords for control over actions; such as size limits, frequency of rotations, location of the results, as well as other actions. In the manual page for logrotate, there are sample configuration files, here's part of one:This means that log backups are compressed, since there are no further compression directives, then the default compression method will be used. It further means that for the specific file /var/log/message, the file will be rotated weekly and keep up to 5 backups. After a rotation, it will also run the post rotation action killall; thus killing the syslogd.

Application Log Perspectives

Being an applications programmer, one for mainly embedded Linux applications, I've actually not learned the system log program functions at all. If you were to ask me how to post an entry into the default system log, I would have to "look it up".

I'm sure these capabilities exist, I've seen applications or services which I've installed and do write to the system log.

My experience not-withstanding, the capability to add logs to the Linux system log sounds very natural and useful, correct?

In my programming world it's not fully what I'd want because the application I've written is custom and it also usually does not care about the specifics of the system, but rather the application's product functions.

Are there some system logs which are relevant to my application's purpose? The answer is yes, but conditionally.

Therefore as a result, the logs for my applications usually reside in an application specific directory. For me, this is a directory under a specific username which was created to be the owner and environment under which the application is run.

To explain further, these apps most always run automatically after system boot and usually take over the entire display, or drive a custom display and the environment is also one where access to the system via command prompts or a window manager are non-existent. Visualize a touch screen for ordering food, or picking up movie tickets. The environments where these applications reside are best designed to automatically load directly into these applications, minimizing the kernel boot time, and showing little or no general purpose availabilities of Linux to the end user.

It may be useful to have a copy of the system log. I have practiced obtaining a "start-up" copy of the system log and placing this copy in my application log directory. I've also designed in measures to get an updated copy of the system log and save that as a "fault" copy of the system log in cases where I detect a problem with the system interface. This potentially allows me to post diagnose some problem in the system which affected my application.

What I have found is that pretty much 100% of the time, it is NOT the fault of the operating system and it was some bug of my own. It may have been mis-use of system library functions, or it may have been a situation where I made incorrect assumptions about the allocation of system devices or resources.

Therefore the system log is typically not too useful for most of my application programming, and instead the separate application logs which I create have been shown to be more useful in "product" diagnosis and debug.

Logrotate for a Custom Application Architecture

Sorry for the very lengthy descriptions there. The points I'm trying to make are:

1. The system log is slightly beneficial in assisting diagnosis of problems with an embedded application.
2. More relevant are the log entries which the programmer creates.
3. In my experiences it is better to segregate your application log entries into different files as opposed to placing them in the general system log, it makes them easier to view, to search, and removes you from viewing general system events which are almost always irrelevant to the operations of your application.

Therefore as a result, we're finally back to my intended purpose; which is the usage of logrotate for your applications logs.

There is no actual magic here. Being the architect of the system, you choose how and when you wish to run logrotate. I either choose to run it directly out of my application, or I set up a script to run logrotate. When you call logrotate, you can pass to it your intended rotation configuration file, I call mine "rotate.cfg"; so whether in a script or passing command arguments via a call to exec(), the call ends up appearing as:And the result is that whatever the rules specified in that custom rotate.cfg file are the rules which logrotate follows. I can also choose to run it once a minute, once and hour, or some other variation of timing which works best for me.

Here is a typical rotate.cfg file which I've used:Note that the daily argument becomes irrelevant because I'm not running logrotate as a system daemon, instead calling it via exec() or a script.

In this case I'll accept up to 10 backup log files and place them in a sub-directory off of my log directory. The missingok argument means that logrotate will not complain if say there are no files matching the pattern *.log.

olddir causes the logs to be moved to this directory before they are rotated. And as you can also see, my size limit for rotation is 20 Megabytes.

Other Notes About These Techniques

1. My preference is to limit log file contents to start-up notifications and feature limiting errors; which is to say, a log file normally shows relevant start-up information about an application process, and then contains little added information; except in the case of a feature limiting error. For instance say a critically needed hardware device which can be either unplugged or fail, does go away for either of those reasons; then the log file will have information appended to reflect this information. Therefore, as a result, the log files I'm used to only contain added data if there is some sort of fault which causes the application not to work properly.
2. When posting entries to log files, I typically perform the full flow of fopen() allowing either append or create, write data, and fclose(). Therefore when the log files do need to be rotated; the files are typically closed, and once the file is moved to the olddir, the way the fopen() is constructed is intended to create a new file if no such file exists.

Conclusions

Not for everyone, I'll reiterate that I'm not here being a system administrator. Merely that somewhere back in time we had limited sized system storage space; we did need to be able to retain logs for a long time so that we could post-diagnose things which happened in the field. You actually get pretty good at determining how and when to post a log and you find that field persons don't always tell you the full story when they complain about problems, but well thought out log archives are very helpful.

Happy Programming!