Hi Folks,
It's spring-clean time again ... Been recovering disk space occupied by stuff I don't really want to know about.
In particular, /var/log/lastlog is 19MB in size, but the output of 'lastlog' is 2225 bytes on 35 lines, telling me *ALL About the Very Last Time Each User Logged In*.[1]
Most of these are, of course "pseudo" users like
bin daemon adm lp sync shutdown halt mail news uucp operator games gopher ftp rpm vcsa nscd sshd rpc rpcuser nfsnobody mailnull smmsp pcap apache xfs named ntp gdm
who never log in anyway!
So that's 19136220/35 = 546749 bytes or half a MB for each "user", and from inspection nearly all of that is bytes with value "00"! (Indeed it gzips down to 18668 bytes, i.e. 1/1000).
Now I can use an extra 19MB of space on that partition (whose free space varies from near-0 to about 400MB depending on what I'm up to), so I'm feeling mean about 19MB devoted to totally boring info.
Hence I'm wondering (a) what's the best way to suppress this lastlog stuff; (b) would it traumatise the system to suppress it?
Thanks for any comments! Best wishes to all, Ted.
[1]. E.g. ftp **Never logged in** ted pts/12 brandy Sun Oct 30 10:09:37 +0000 2005
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 30-Oct-05 Time: 10:41:23 ------------------------------ XFMail ------------------------------
A curious squel to my previous mail (below). See at end.
On 30-Oct-05 Ted Harding wrote:
Hi Folks,
It's spring-clean time again ... Been recovering disk space occupied by stuff I don't really want to know about.
In particular, /var/log/lastlog is 19MB in size, but the output of 'lastlog' is 2225 bytes on 35 lines, telling me *ALL About the Very Last Time Each User Logged In*.[1]
Most of these are, of course "pseudo" users like
bin daemon adm lp sync shutdown halt mail news uucp operator games gopher ftp rpm vcsa nscd sshd rpc rpcuser nfsnobody mailnull smmsp pcap apache xfs named ntp gdm
who never log in anyway!
So that's 19136220/35 = 546749 bytes or half a MB for each "user", and from inspection nearly all of that is bytes with value "00"! (Indeed it gzips down to 18668 bytes, i.e. 1/1000).
Now I can use an extra 19MB of space on that partition (whose free space varies from near-0 to about 400MB depending on what I'm up to), so I'm feeling mean about 19MB devoted to totally boring info.
Hence I'm wondering (a) what's the best way to suppress this lastlog stuff; (b) would it traumatise the system to suppress it?
Thanks for any comments! Best wishes to all, Ted.
[1]. E.g. ftp **Never logged in** ted pts/12 brandy Sun Oct 30 10:09:37 +0000 2005 ===============================================================
I do a 'ls -lsr /var/log' and I see
... 72 -rw-r--r-- 1 root root 66459 Oct 30 13:13 ksyms.0 72 -rw------- 1 root root 68095 Oct 16 04:02 messages.3 80 -rw------- 1 root root 77295 Oct 23 04:03 messages.2 204 -rw------- 1 root root 204284 Oct 9 04:02 messages.4 320 -rw-rw-r-- 1 root utmp 322944 Sep 30 20:40 wtmp.1 584 -rw-rw-r-- 1 root utmp 590592 Oct 30 14:20 wtmp 44 -r-------- 1 root root 19136220 Oct 30 14:16 lastlog
The size in 1K blocks of 'lastlog' is at variance with its size in bytes -- the others (included as examples) are OK.
Given the grossly enormous size of this file, I began to wonder if I have my inodes scrambled. OK, check what actually comes out if you 'cat' the file:
# cat /var/log/lastlog | wc -c 19136220
which agrees with the byte-size from 'ls'. This should be OK, because 'wc -c' is counting the bytes that come out of 'cat'.
Just to check (differently):
# od -x /var/log/lastlog 0000000 d556 4364 7474 3179 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 * 0435120 d5d8 4364 7474 3279 0000 0000 0000 0000 0435140 0000 0000 0000 0000 0000 0000 0000 0000 * 0436220 0000 0000 0000 0000 44e5 40ec 7474 3379 0436240 0000 0000 0000 0000 0000 0000 0000 0000 * 110777320 0000 0000 0000 0000 0000 0000 110777334
where the "*"s represent suppressed duplicate lines, and the number in the last line is the index of the next byte to come (hence equals number of bytes), in base 8. To do the conversion to decimal:
# bc bc 1.06 Copyright 1991-1994, ... (blah) ibase=8 110777334 19136220 quit
which again agrees.
At this stage, check similarly on my other two up-and-running machines.
Machine A:
... 3 -rw-r--r-- 1 root root 2773 Oct 27 12:58 boot.msg 5 -rw-r--r-- 1 root root 4539 Feb 1 1998 Config.bootup 3 -rw------- 1 root root 12216 Oct 30 14:22 faillog 16 -rw-r--r-- 1 root root 15272 Oct 27 12:58 httpd.error_log 3 -rw-r--r-- 1 root root 16128 Oct 30 14:22 lastlog 27 -rw-r----- 1 root root 25752 Feb 8 2005 warn-050208.gz 47 -rw-r--r-- 1 root root 46763 Aug 11 2004 wtmp-040811.gz 75 -rw-r----- 1 root root 75720 Oct 27 12:58 warn ...
showing that there's the same issue here with 'lastlog' but ALSO with 'faillog'! The 1K block size is a fraction of that it should be for the byte size.
Well, now for machine B:
... 8 -rw-r----- 1 root root 7804 Oct 30 15:07 warn 12 -rw-r--r-- 1 root root 8867 Oct 30 15:06 boot.msg 12 -rw-r--r-- 1 root root 10093 Oct 30 15:04 boot.omsg 8 -rw------- 1 root root 12072 Oct 30 15:07 faillog 16 -rw-r----- 1 root root 12512 Oct 30 15:07 firewall ... 80 -rw-r----- 1 root root 77653 Jul 13 00:15 warn-20050713.gz 148 -rw-r--r-- 1 root root 146377 Jan 27 2004 y2log 16 -rw-r--r-- 1 root tty 146876 Oct 30 15:07 lastlog ...
which shows the same thing as A for both 'lastlog' and 'faillog'.
So: is there a kind of file which is stored in a small number of physical byte-slots on the hard drive, and therefore occupies a small space in the file-system (as exhibited by the block size in the column 1 above), while its byte-size -- which becomes apparent if it is extracted by a program -- is much larger (as exhibited by the byte size in column 6 above)?
Is this peculiar to this kind of 'log' file (as exemplified by faollog and lastlog above)?
I hadn't heard of such a thing.
A and B, by the way, are using ext2 filesystems (A from about 1997), while the third one (the one that started all this off) is using ext3 (Red Hat 9 from 2003).
Hmmm. Any comments? Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 30-Oct-05 Time: 16:21:56 ------------------------------ XFMail ------------------------------
On 30-Oct-05 Tim Green wrote:
On 10/30/05, Ted Harding Ted.Harding@nessie.mcc.ac.uk wrote:
Hmmm. Any comments?
Sparse files?
So it seems (and I hadn't heard of these before).
Meanwhile, googling around, I came across a couple of interesting discussion of the issue:
http://www.linuxquestions.org/questions/archive/14/2003/03/4/51312
Search the page for "sparse",, and read on.
https://lists.dulug.duke.edu/pipermail/dulug/2005-July/016373.html
and follow the thread (started by a guy who's 'lastlog' was bigger than his hard drive).
I was particularly tickled by the dependency on user id, and the consequences of the fact the "user" nfsnobody = -1 (especially in a 64-but system).
Ah well, one learns!
Cheers, Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 30-Oct-05 Time: 17:50:14 ------------------------------ XFMail ------------------------------