Red Hat Bugzilla – Bug 55179
/var/log/lastlog not rotated
Last modified: 2007-04-18 12:37:48 EDT
Description of Problem:
Despite the text in /etc/logrotate.conf, only wtmp is being rotated,
not lastlog. On a busy machine, this file can grow way too big.
Version-Release number of selected component (if applicable):
look for lastlog in /etc/logrotate* /etc/logrotate/*/*; notice nothing
I notice that this file is exceptionally huge on every RedHat 7.2 machine with
errata as of 10/26/2001. On every such machine, the filesize is approx. 19M.
Every RedHat 7.1 machine I could find (even with updated kernel, etc) have the
more typical 150K size.
Can anyone else confirm an unusually large /var/log/lastlog file? I've never
seen it so big except w/ 7.2 +errata. Haven't seen any changes to shadow-utils,
glibc, etc. that seem relevant.
The lastlog file's size is bounded - it will not grow infinitely. It is an array
of (login_time, login_terminal, login_host) tuples, indexed by UID.
The size shown by 'ls -l' may not be accurate, because large pieces of the file
may be sparse due to gaps in the active UID space. You should use 'du -h
/var/log/lastlog' to find out the true size. (For example, on my machine the ls
-l size is 18M, while the du -h size is 29k.)
It doesn't make sense to rotate this file, because it is not a time series like
regular log files.
OK, even with an index by UID, I'm thinking that something that writes to
/var/log/lastlog *sometime* did so erroneously, because:
1. If I remove (or zero out) the file, I get normal sizes... approx. 150K
after system activity.
2. How big would a UID have to be to force the creation of a 19 megabyte
"lastlog" file? The biggest UID I have is the "nfsnobody" one which is
something like 65534. The filesize just seems too big. I'm guessing that
someone opened this in the first place because he/she saw this huge file sitting
in /var/log and assumed it was a growing one as opposed to an indexed one as you
I will see if my now normal 150K size file ever jumps back up to the 18-19
megabyte range now that I've "zapped" it.
Each lastlog entry is 296 bytes in size.
[sopwith@ostrich-deluxe apiary]$ ls -l /var/log/lastlog
-rw-r--r-- 1 root root 19398360 Oct 24 11:15 /var/log/lastlog
ans = 65535
Looks about right to me, although I don't know how nfsnobody ever tried to login...
OK. Thanks for the explanation. Upon further investigation, I found that the
"useradd" utility in shadow-utils package zeros out the lastlog entry for the
chosen UID, in this case 65534.
From a quick check against a 7.1 system, I'm guessing this is the first time
that a "high" UID was chosen, and so this behavior wasn't detected before.
Also, I get filesizes that a multiples of 292 as opposed to 296...interesting...
*** Bug 57331 has been marked as a duplicate of this bug. ***