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.
I want to mention that I ran fsck.ext3 with the force (-f) option since it was 'clean'.
logrotate doesn't touch lastlog. This is expected on 64-bit arches, AFAIK. It *is* a sparse file.
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
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
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.
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?
It is a sparse file. It does not actually occupy 1TB of space.
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.
Open a separate bug on that... that would be a different error.
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