Red Hat Bugzilla – Bug 144538
'nfsnobody' UID causes huge /var/log/lastlog
Last modified: 2007-11-30 17:10:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
Related to the bug mentioned here:
When doing an install of FC3 on an Opteron system, the
/var/log/lastlog file would fill all of /var causing the install to
fail. While the file should be sparse, and therefore "appear" larger
than it is, I wonder if the problem is related to differences in how
ReiserFS deals with sparse files (which is the FS used in this case).
ie, in that bug, the user said that 'ls' showed the inflated size,
while 'du' showed the "real" size. On my machine it does the opposite.
Either way, the solution was to remove the file during the install,
and before nfs-utils installed and created the nfsnobody user. Then
change the UID and GID for nfsnobody to 65534 and touch
/var/log/lastlog so it can be created on next login.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC3 on x86_64 with ReiserFS for /var
2. Wait for nfs-utils to be installed
3. /mnt/sysimage/var is now full, install fails as RPM complains
Actual Results: Install failed with error messages that the disk was full
Expected Results: Either the file shouldn't be that large (sparse
files in ReiserFS issue), or the UID/GID number should be 65535, which
would cure the symptom but not necessarily the problem.
Setting high, as this would affect anyone trying to do an install with
ReiserFS and a disk smaller than 1TB
This also happens on RHEL4 x86-64... on a fresh install, /var/log/lastlog is
1.2T causing problems for some programs
This also occurs on RHEL3 x86_64 - I'm wondering if this is
*exclusively* a 64-bit issue?
*** This bug has been marked as a duplicate of 165058 ***