In article <[EMAIL PROTECTED]>, montefin <[EMAIL PROTECTED]> wrote: >Has anyone else encountered this situation?
Yes, almost everyone. >I was looking at my /var/log directory and this popped out at me >-rw-rw-r-- 1 root utmp 18692964 May 17 04:19 lastlog > >I'm still tweaking a recent upgrade from Slink to Potato, so I guess I >do a lot of su - logins, but still isn't that an enormous file for its >purpose? No. Do a "du /var/log/lastlog" - you'll see that it's just a few K. >'man lastlog' does have a cautionary statement about wide gaps in uid >#'s slowing down the time it takes for lastlog to print to screen when a >user logs in. That isn't quite what the manual page says, the manpage is confusing and incomplete though. >And, as a consequence of having qmail installed I do have huge gaps in >uid's because Debian requires the 7 qmail uid's to be 64010 to 64016. >Could this have any bearing on the huge size of the log file? It isn't huge - it just has enormous holes in it. And holes do not take up real disk space. This is a feature of Unix called "sparse files". >Even so, is there some command I can issue to flush the log so I can >keep it in proportion? Or will some regular process eventually reduce >the size of /var/log/lastlog and free up that disk space? Not needed. Try the "du /var/log/lastlog" command to see how much space it _actually_ uses and be amazed ;) Someone should fix/update the manpage though: - mention that the effect under CAVEATS only happens when lastlog is called without -u - explain how the lastlog file works, and why it appears to be bigger than it is. Or just point to lastlog(5) which should then ofcourse be written Mike.
