Lastlog mysteries

Question

Hi,
I recently stumbled over a gigantic lastlog file in /private/var/log of about 4.5 GB . Using a small perl script (see at the bottom) I could read lastlog, but found only a few dozen lines with login info.
I deleted the file as root (now filesize 1), logged out and in again.
Now the filesize was 28868 containing only two lines of text with my last login info. I understand that this is a "sparse" file containing lots of zeroes which upon backup are ignored by tar aso. But 32K for two lines of text is 32K.
I'm puzzled by all this. What is the sense of a logfile with login info which is not readable by normal means and consumes **** of disk space ? Can anybody enligthen me ?
#!/usr/bin/perl -w
require 'ctime.pl';
$utSize = 28;
$utTemplate = 'l A8 A16';
$utBuffer = ' ' x $utSize;
$uid = 0;
open (LASTLOG, '</private/var/log/lastlog') || die "can't open lastlog ($!)\n";
while (sysread (LASTLOG, $utBuffer, $utSize) == $utSize)
($time, $line, $host) = unpack ($utTemplate, $utBuffer);
if ($time != 0)
$user = (getpwuid ($uid))[0];
print "$user on $line ";
print $host eq '' ? "(local)" : "from $host";
print " at ", &ctime ($time);
$uid++;
close (LASTLOG) || die "can't close lastlog ($!)\n";
OSX Server   Mac OS X (10.4.8)  

Answer 1

Sir, please !!
> But it does not answer why lastlog is redundant
with wtmp
It isn't redundant. They store different data. OK,
fair enough, there is some overlap, but the
fundamental data is different.
Which fundamental data ?
> why unlike other log files its a binary
It should be binary. A text file is too easy
to edit to hide your tracks (if you're trying to hide
the fact you were there).
You need root access to edit log files. If you have hacked the root password you can do anything anywhere anyway.
> why a sparse file
No idea.
Correct.
why so gigantic over time
Because it's perpetual and doesn't get cleaned up.
Right or wrong I'm not saying.
Thats the observation, not the explanation.
> why it is not rolled in /etc/weekly like other
log files
Because it's a binary file, not a text file like
other log files. In addition, because it's keeping
state, you can't just remove the old file and start a
new one without risking corruption of the file.
You cannot gzip a binary file, no ?
That's not to say there shouldn't be some
process for managing the file, but it's not as simple
as you might think.
Your estimated guess. I miss the knowledge, though.
In fact there is ample discussion about lastlog and its design flaws and the backup and insane space consumption problems a sparse file implies (http://www.redhat.com/archives/fedora-test-list/2005-June/msg00324.html ) . Listen to this one:
"And the file is just ancient cruft anyway. It stores the last login
time, terminal device (or X server), and remote host for each user. I
found a couple of non-glibc utilities that write to the file
(dhclient, useradd), but only one that actually cares to read it
(lastlog(8), which can only be run by root). If this thing went away
tomorrow, I doubt anyone would notice. Meaningful user login auditing
is done with other tools. Note also that this is a BSD feature, and isn't part of the SUSv2 spec. In 1979 on a VAX with 16 bit UIDs, this might have been a
worthwhile use of space (I found a 3BSD header that defined the
lastlog struct as a 12 bytes; the current glibc structure is 292 bytes
long). On a modern 64 bit linux, it leads to the 1.2TB monstrosity
we're shouting about. To all the "not a bug" folks: if you were
charged with deciding on a file format for storing 2 strings and a
time for each user, would this honestly be your choice?
Finally, note that its functionality is 100% duplicated by the wtmp
file and last(1) tool anyway (except for the misfeature of not storing the
user name and thus being unable to track changes in the passwd file).
One could duplicate lastlog(8) using last(1) with a few lines of perl. This file is a silly side effect of the change to 32 bit UIDs, and needs to be fixed."
The lastlog file is a *nix dinosaur left over from ancient times. OSX should do better. Anybody from Apple listening ?