What determines when logs get rotated?

Question

I need to write a script to parse /private/var/log/secure.log and create a report consisting of the time and userid of each login. But secure.log gets archived periodically, and then the archives get deleted, so I need to time the execution of this script to whatever it is that triggers this archiving so I can record the logins before the log gets rotated.
Looking at the logs and archives, it's a little hard to tell what's going on.
% ls -l /private/var/log/secure.*
-rw-r----- 1 root admin 8153 Jul 24 21:37 /private/var/log/secure.log
-rw-r----- 1 root admin 2232 Jul 21 23:16 /private/var/log/secure.log.0.gz
-rw-r----- 1 root admin 2196 Jul 7 08:21 /private/var/log/secure.log.1.gz
-rw------- 1 root admin 6275 Jun 29 22:29 /private/var/log/secure.log.2.gz
The time intervals are not the same, and neither are the file sizes, so the logs don't appear to get rotated on a regular schedule or when they reach a certain size. It does seem to happen between logins, I think.
/private/etc/periodic/daily/100.clean-logs looks like it deletes old logs, but it isn't involved in archiving or deleting archived logs. /private/etc/periodic/daily/500.daily has a routine for archiving logs, but I don't understand it well enough to see what triggers it.

Answer 1

I've written the script for doing user accounting on the Panther machines, but I'm still having trouble understanding what's going on on my own machine. I'm not positive, but I think there might be some serious problems with launchd and how it manages logs. Something is definitely not right.
According to the documentation Mark referred me to,
Beginning in Mac OS X v10.4, the preferred way to add a timed job is to use a launchd(8) timed job. A launchd timed job is similar to a cron(8) job, with two key differences:
* Each launchd job is described by a separate file. This means that you can add launchd timed jobs by simply adding or removing a file.
* If the computer is asleep at the designated time, a launchd job executes as soon as the computer wakes. This is similar to the behavior of anacron and other cron replacements).
From what I'm seeing, this simply isn't happening. Look at the listing I posted above:
% ls -l /private/var/log/secure.*
-rw-r----- 1 root admin 8153 Jul 24 21:37 /private/var/log/secure.log
-rw-r----- 1 root admin 2232 Jul 21 23:16 /private/var/log/secure.log.0.gz
-rw-r----- 1 root admin 2196 Jul 7 08:21 /private/var/log/secure.log.1.gz
-rw------- 1 root admin 6275 Jun 29 22:29 /private/var/log/secure.log.2.gz
This log is rotated by the script /private/etc/periodic/weekly/500.weekly, but it clearly isn't being rotated weekly. The dates the three archives were created fall on a Friday and two Saturdays, and there is a two week gap between 0 and 1. I am positive that my laptop was not asleep for a week or more. I use it every day. I noticed that the permissions on secure.log.2.gz are wrong, but I don't think that's the cause of the problem. It's just another sign of the hinkiness that abounds here.
The situation looks even stranger when you look at the dates of the first and last entries in each file:
secure.log.2: Jun 19 22:34:51 - Jun 29 22:29:19
secure.log.1: Jun 30 20:15:36 - Jul 7 08:20:33
secure.log.0: Jul 7 11:33:01 - Jul 21 23:16:07
secure.log: Jul 22 15:35:03 - Jul 27 22:43:46 (and counting)
So it looks secure.log.0 and secure.log.2 were truncated and archived around midnight--different days of the week, but at least they avoided getting entries from the same date in two different files. But look at secure.log.1. 8:21 in the morning??? Why???? It's not like it was asleep or anything. I had been using it until around 12:30, and started in again at around 6:30 Saturday morning. Why does it decide it's time to rotate the log at 8:21? And this is after it has already waited two weeks!
So if you're doing user accounting on a weekly basis, this just isn't helpful, and it sure isn't helpful if you're trying to do it monthly. You basically need to re-concatenate the files and split them out by grepping the dates. In other words, before you can do what you need to do, you have to undo what the periodic maintenance routines have done.
And you have to hope they haven't destroyed the records you need.
Among all the other mysteries I'm trying to sort out, I'm trying to understand why the /private/etc/periodic/monthly/500.monthly script didn't run at the end of June. One thing I can't do is go back and look at the system.log, because they rotate them daily (or they intend to, but this doesn't work correctly either) and only keep the last seven. Here's what the log rotation script looks like:
for i in system.log; do
if \[ -f "${i}" \]; then
printf %s " ${i}"
if \[ -x /usr/bin/gzip \]; then gzext=".gz"; else gzext=""; fi
if \[ -f "${i}.6${gzext}" \]; then mv -f "${i}.6${gzext}" "${i}.7${gzext}"; fi
if \[ -f "${i}.5${gzext}" \]; then mv -f "${i}.5${gzext}" "${i}.6${gzext}"; fi
if \[ -f "${i}.4${gzext}" \]; then mv -f "${i}.4${gzext}" "${i}.5${gzext}"; fi
if \[ -f "${i}.3${gzext}" \]; then mv -f "${i}.3${gzext}" "${i}.4${gzext}"; fi
if \[ -f "${i}.2${gzext}" \]; then mv -f "${i}.2${gzext}" "${i}.3${gzext}"; fi
if \[ -f "${i}.1${gzext}" \]; then mv -f "${i}.1${gzext}" "${i}.2${gzext}"; fi
if \[ -f "${i}.0${gzext}" \]; then mv -f "${i}.0${gzext}" "${i}.1${gzext}"; fi
if \[ -f "${i}" \]; then
touch "${i}.$$" && chmod 640 "${i}.$$" && chown root:admin "${i}.$$"
mv -f "${i}" "${i}.0" && mv "${i}.$$" "${i}" && if \[ -x /usr/bin/gzip \]; then
gzip -9 "${i}.0"; fi
fi
fi
done
That last part is just plain weird. They get done rotating all the gzipped archives, and then they need to test to see if there is a new log file, and if not, create one, then archive it. Archive an empty log??? What for? Don't you want to see if there's a current log, and that it has at least one line of data in it, before you start the whole process? Why bother rotating logs if there's no new information? And then, after they archive it, they don't create a new log? All of the other log rotation scripts archive the current log then create a new one. Why should this one be different? This just looks like a mistake.
Also, I'm not the most experienced shell scripter, but isn't this just plain crude and ugly? Instead of using a loop to do a repetetive task, with a variable you can change to set a limit on the number of iterations, they've hard-coded each step. And this is in the script that we're not supposed to change, and it can't be overridden. Nice.
So if we want to change how frequently our log files get trashed, we need to write a daily.local script that takes the truncated, archived files and decompresses them, concatenates them, and puts them somewhere out of harms way? Is that how we're supposed to proceed? Follow them around and undo what they do then try to do it right? Heaping more ugliness upon ugliness?
And keep in mind that the timing mechanism that controls it all is broken, and if you want to do your monthly reports at the end of the month, or your weekly reports at the end of the week, you either have to wait around until this byzantine Rube Goldberg machine spits out the logs you need or go to the terminal and call periodic to run whatever process you want it to run manually after all.
I am starting to wish I'd never looked at this.