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): logrotate-3.5.9-1 How Reproducible: 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 say. 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 octave:2> 19398360/296 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. ***