Bug 138676

Summary:	lastlog >1TB on fresh install
Product:	[Fedora] Fedora	Reporter:	Bryan Stillwell <bryans>
Component:	setup	Assignee:	Bill Nottingham <notting>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	axel.thimm, bugs-redhat, mvermaes, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-11-10 17:51:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bryan Stillwell 2004-11-10 17:28:38 UTC

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 17:38:10 UTC

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 17:51:44 UTC

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 17:59:43 UTC

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 18:03:39 UTC

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 18:12:11 UTC

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 21:57:55 UTC

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 22:03:45 UTC

It is a sparse file. It does not actually occupy 1TB of space.

Comment 8 Steve Huston 2005-01-07 22:29:23 UTC

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 22:39:14 UTC

Open a separate bug on that... that would be a different error.

Comment 10 Aleksander Adamowski 2006-04-12 13:59:21 UTC

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