Bug 55179 - /var/log/lastlog not rotated
/var/log/lastlog not rotated
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: logrotate (Show other bugs)
7.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Elliot Lee
Aaron Brown
:
: 57331 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-26 13:44 EDT by Frank Ch. Eigler
Modified: 2007-04-18 12:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-27 00:51:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Ch. Eigler 2001-10-26 13:44:20 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):
logrotate-3.5.9-1

How Reproducible:
look for lastlog in /etc/logrotate* /etc/logrotate/*/*; notice nothing
Comment 1 Greg Bailey 2001-10-27 00:51:46 EDT
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.
Comment 2 Elliot Lee 2001-10-27 20:22:58 EDT
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.
Comment 3 Greg Bailey 2001-10-27 23:48:13 EDT
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.
Comment 4 Elliot Lee 2001-10-28 00:23:14 EDT
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...
Comment 5 Greg Bailey 2001-10-29 15:17:27 EST
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...
Comment 6 Elliot Lee 2001-12-10 11:25:46 EST
*** Bug 57331 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.