[Freeipa-users] Large lastlog from large UIDs

[Simo Sorce]

On Mon, 2012-01-02 at 15:47 -0900, Erinn Looney-Triggs wrote:
> While digging through and trying to investigate a file system slowdown
> that may or may not be IPA related, I noticed an odd thing on my RHEL 5
> and 6 based systems, the lastlog file was bloody huge:
> 
> -rw-r--r-- 1 root root 469419202628 Jan  3 00:20 /var/log/lastlog
> 
> Or for those of us who don't count that high .
> 
> -rw-r--r-- 1 root root 438G Jan  3 00:20 /var/log/lastlog
> 
> Now really it isn't that big:
> 
> erinn at uat ~ $ du -sh /var/log/lastlog
> 64K     /var/log/lastlog
> 
> However, and I am no expert here, some backup programs will choke hard
> on this file, because it appears all that empty space will actually get
> nulled out, or at least this is happening to me with Bacula 5.0.2 on
> RHEL 5. More investigation into this part is necessary though...
> 
> Now at a guess, this is probably related to this blog post:
> http://linuxshellaccount.blogspot.com/2007/11/trimming-space-in-var-problem-with.html
> 
> That article was written for Solaris but it sure seems to be applicable
> to Linux as well. Though the multiples aren't the same.
> 
> Frustratingly, this does not seem to be the case with all of my systems,
> only some of them. I have multiple RHEL 5 and 6 instances exhibiting
> this issue, and one RHEL 5 system that is not.
> 
> This is probably a result of IPA choosing ludicrously high UIDs to avoid
> collisions (which is fine, no bashing here).
> 
> Can anyone else confirm? Lend more insight?

I can confirm.
apparently lastlog programmers decided that using sparse files to
implement a hash table where the key is the uid number was a good
idea ...

Can you please file a bug against RHEL and CC me ?

I am not sure what we do for RHEL5/RHEL6 as I don't know if the lastlof
file format changes is considered an aBI change but we can certainly
prevent this from happening in Fedora and RHEL7.

I think, meanwhile you may want to exclude lastlog from backups or bzip2
it before backing it up.

Thanks for reporting this.
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York