Bug 138676 - lastlog >1TB on fresh install
lastlog >1TB on fresh install
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-10 12:28 EST by Bryan Stillwell
Modified: 2016-01-29 00:38 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-10 12:51:44 EST
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 Bryan Stillwell 2004-11-10 12:28:38 EST
Description of problem:
After a fresh install on Fedora Core 3 for x86_64, I found the file
/var/log/lastlog to be of very large size (>1TB).  It appears to be
getting created as a sparse file, but I couldn't think of a reason for
this.  I'm also pretty sure this will cause problems with logrotate.

Version-Release number of selected component (if applicable):
setup-2.5.36-1

How reproducible:
Do a fresh 'minimal' install of fc3 on an opteron machine.  Notice
after the first reboot that /var/log/lastlog is very large:

# ls -l lastlog
-r--------  1 root root 1254130450140 Nov 10 10:08 lastlog
# du -h lastlog
44K     lastlog

I tried doing this with the default auto-partition and selinux turned
on, and again with manually partitioning and selinux off.

Steps to Reproduce:
1. Do a minimal install of FC3
2. Reboot, and check out size of /var/log/lastlog
  
Actual results:
lastlog was greater than 1TB

Expected results:
lastlog to be under 1MB initially

Additional info:
I tried opening the filesystem with debugfs, then the file using mi
(modify inode).  The 'size' was -291 and the 'high 32bits of size' was
292 (or something close to those numbers.  The first 6 'direct blocks'
(#0-5) were set, but then the rest of the 'direct blocks' (#6-11), the
'indirect block', and the 'double indirect block' were set to 0. 
However, the 'triple indirect block' was set.   fsck.ext3 didn't
report any filesystem problems...

I set severity to high because of the logrotate issue.
Comment 1 Bryan Stillwell 2004-11-10 12:38:10 EST
I want to mention that I ran fsck.ext3 with the force (-f) option
since it was 'clean'.
Comment 2 Bill Nottingham 2004-11-10 12:51:44 EST
logrotate doesn't touch lastlog.

This is expected on 64-bit arches, AFAIK. It *is* a sparse file.
Comment 3 Bryan Stillwell 2004-11-10 12:59:43 EST
On FC1 and FC2 x86_64 installs, it may be ~19MB, but that's still many
gigabytes less than what the FC3 reports.

System 1 (FC1):
# ls -l lastlog
-r--------    1 root     root     19136220 Nov 10 11:58 lastlog
# du -h lastlog
44K     lastlog
# uname -a
Linux master 2.4.22-1.2199.nptlsmp #1 SMP Wed Aug 4 11:19:36 EDT 2004
x86_64 x86_64 x86_64 GNU/Linux

System 2 (FC2):
# ls -l lastlog
-r--------  1 root root 19136220 Nov 10 11:01 lastlog
# du -h lastlog
52K     lastlog
# uname -a
Linux master1 2.6.7-1.494.2.2smp #1 SMP Tue Aug 3 09:34:09 EDT 2004
x86_64 x86_64 x86_64 GNU/Linux
Comment 4 Bryan Stillwell 2004-11-10 13:03:39 EST
I think I found the reason for the large file size.  Taking a look at
the /etc/passwd file, we have this user:

nfsnobody:x:4294967294:4294967294:Anonymous NFS
User:/var/lib/nfs:/sbin/nologin
Comment 5 Bryan Stillwell 2004-11-10 13:12:11 EST
Same problem as the following bug it appears:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134803

Apparently system-config-users-1.2.23 fixes the problem.
Comment 6 Steve Huston 2005-01-07 16:57:55 EST
So, it's *expected* that installing FC3 on an x86_64 system, that you
must have at least 1TB of space available for /var/log/lastlog?
Comment 7 Bill Nottingham 2005-01-07 17:03:45 EST
It is a sparse file. It does not actually occupy 1TB of space.
Comment 8 Steve Huston 2005-01-07 17:29:23 EST
Tell that to RPM, which during the install starts complaining "Unable
to write to device" because /var is full.


Solution was to change to the shell as soon as /var/log/lastlog was
created, and delete it.  Once system boots, change 'nfsnobody' UID/GID
to 65534, and touch /var/log/lastlog.
Comment 9 Bill Nottingham 2005-01-07 17:39:14 EST
Open a separate bug on that... that would be a different error.
Comment 10 Aleksander Adamowski 2006-04-12 09:59:21 EDT
What about problems with third party software that doesn't dig sparse files?

For example Tivoli Storage Manager 5.2 for x86 run on x86_64 complains:


Normal File-->   1,254,130,450,140 /var/log/lastlog  ** Unsuccessful **
ANS1228E Sending of object '/var/log/lastlog' failed
ANS1311E Server out of data storage space

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