lastlog is huge

[david smethurst]

hi all 
ive been trying to ghost over my drives from 160gb to a  36gb and
couldnt figure out why it keep saying that the destination drive was too
small.
then i found this:
in /var/log/lastlog is 1168.0GB
its locked of course but please what can i do about this and why is it
so big?
the drive is not big enough for the size so something else is wrong
question? how can i tell how big everything is?
i tried to use the file size view in konqueror and it just keeps locking
up all the time so that i cant use it anymore and go to the home
directory
thanks for any help
david

[Paul Howarth]

david smethurst wrote:
>  hi all 
>  ive been trying to ghost over my drives from 160gb to a  36gb and
>  couldnt figure out why it keep saying that the destination drive was too
>  small.
>  then i found this:
>  in /var/log/lastlog is 1168.0GB
>  its locked of course but please what can i do about this and why is it
>  so big?
>  the drive is not big enough for the size so something else is wrong
>  question? how can i tell how big everything is?
>  i tried to use the file size view in konqueror and it just keeps locking
>  up all the time so that i cant use it anymore and go to the home
>  directory 
/var/log/lastlog is a sparse file. See 
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/...

for an explanation of sparse files.

# du -k /var/log/lastlog
will tell you how many kilobytes it's actually taking up on disk.

Paul.

[Hacksaw]

Seems like something is getting logged there a lot, which is kind of odd. Does 
this machine have a lot of users?

In any case, it's just a log of who has logged in and when. If you don't need 
that history, delete the file as root. The machinery will create it as needed.

You might look into logrotate, which would help keep it to a reasonable size.

-- 
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD

[Dave Mitchell]

On Tue, Mar 01, 2005 at 06:00:00AM -0500, Hacksaw wrote:
>  Seems like something is getting logged there a lot, which is kind of
> odd. Does 
>  this machine have a lot of users?
>  
>  In any case, it's just a log of who has logged in and when. If you don't need 
>  that history, delete the file as root. The machinery will create it as needed.
>  
>  You might look into logrotate, which would help keep it to a reasonable size. 
lastlog is a *sparse* file that only records the last login of each user
at a fixed offset in the file (indexed by uid). If you have a user with a
large uid, the file will appear huge, but ls -s will show the true size.

Log rotation will not help at all.

-- 
A major Starfleet emergency breaks out near the Enterprise, but
fortunately some other ships in the area are able to deal with it to
everyone's satisfaction.
    -- Things That Never Happen in "Star Trek" #13

[Hacksaw]

> lastlog is a *sparse* file that only records the last login of each
> user
> at a fixed offset in the file (indexed by uid). If you have a user with a
> large uid, the file will appear huge, but ls -s will show the true size.
>
> Log rotation will not help at all. 
True enough.

I must say that I find this to be of dubious utility. I suppose it's faster, 
but how many people look at lastlog so often that it needs to be as fast as 
possible? Even in the good old days when Linux was a baby penguin and real men 
wrote code on Hazeltine terminals, one called lastlog at most a few times in a 
day, mostly to see if friends had been on.

Surely a hash file makes more sense?

Oh well, maybe I'll send someone some email...
-- 
Sharp tools prevent accidents, and foster intent.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD

[Paul Howarth]

Hacksaw wrote:
> >lastlog is a *sparse* file that only records the last login of
> each user
> >at a fixed offset in the file (indexed by uid). If you have a user with a
> >large uid, the file will appear huge, but ls -s will show the true size.
> >
> >Log rotation will not help at all.
>  
>  
>  True enough.
>  
>  I must say that I find this to be of dubious utility. I suppose it's faster, 
>  but how many people look at lastlog so often that it needs to be as fast as 
>  possible? Even in the good old days when Linux was a baby penguin and real men 
>  wrote code on Hazeltine terminals, one called lastlog at most a few times in a 
>  day, mostly to see if friends had been on.
>  
>  Surely a hash file makes more sense? 
The way sparse files work means that it *is* effectively a hashed 
database, with all the clever stuff done at filesystem level. This is 
how *nix systems have done this sort of thing for aeons...

Paul.

[Hacksaw]

> how *nix systems have done this sort of thing for aeons... 
One wonders, then, why the basic utils, like cp and mv don't deal with it 
better?
-- 
Omnia plures altus Latina videt
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD

[Paul Howarth]

Hacksaw wrote:
> >how *nix systems have done this sort of thing for aeons...
>  
>  
>  One wonders, then, why the basic utils, like cp and mv don't deal with it 
>  better? 
The cp manpage says that it does attempt to handle sparse files properly 
- see the --sparse option.

Paul.

[Hacksaw]

>  One wonders, then, why the basic utils, like cp and mv don't deal
> with it 
>  better? 
Sorry, I was hearkening back to the explication of the link first offered to 
explain sparse files.

Though I note that "man mv" doesn't mention them at all.


-- 
Powered by beta particles
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD

[Tim Waugh]

On Tue, Mar 01, 2005 at 06:32:09AM -0500, Hacksaw wrote:

>  >how *nix systems have done this sort of thing for aeons...
>  
>  One wonders, then, why the basic utils, like cp and mv don't deal with it 
>  better? 
In what way don't cp or mv handle sparse files correctly?

Tim.
*/

[Aleksandar Milivojevic]

Hacksaw wrote:
>  One wonders, then, why the basic utils, like cp and mv don't deal
> with it 
>  better? 
Cp deals with it.  Info page for mv says that mv is using same code as 
"cp -a" when moving files from one file system to another.  When moving 
files within single file system, the file actually stays where it was on 
the disk.  Only pointer from directory structure is moved from one place 
to another (try it, if "a" is 10GB file, than "mv a b" will be almost

instant).

-- 
Aleksandar Milivojevic <amilivojevic(a)pbl.ca&gt;    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: [phone] ext 276                     Winnipeg, MB  R3T 1L7

[Alexander Dalloz]

Am Di, den 01.03.2005 schrieb david smethurst um 11:47:

>  ive been trying to ghost over my drives from 160gb to a  36gb and
>  couldnt figure out why it keep saying that the destination drive was too
>  small.
>  then i found this:
>  in /var/log/lastlog is 1168.0GB 
>  david 
Some day ago a reply by Arjan van de Ven about the same observation on
an RHEL4 host:

"if this is a 64 bit machine... the nfs nobody user has UID of -1...
which is a lot on 64 bit"

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.14_FC2smp 
Serendipity 16:02:26 up 8 days, 3:11, load average: 0.18, 0.64, 0.50

[Aleksandar Milivojevic]

Alexander Dalloz wrote:
>  "if this is a 64 bit machine... the nfs nobody user has UID of
> -1...
>  which is a lot on 64 bit" 
Good thing nobody logs in as nobody :-)

Or is there anybody?

-- 
Aleksandar Milivojevic <amilivojevic(a)pbl.ca&gt;    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: [phone] ext 276                     Winnipeg, MB  R3T 1L7

[Matthew Miller]

On Tue, Mar 01, 2005 at 09:19:01AM -0600, Aleksandar Milivojevic wrote:
>  >"if this is a 64 bit machine... the nfs nobody user has UID
> of -1...
>  >which is a lot on 64 bit"
>  Good thing nobody logs in as nobody :-)
>  Or is there anybody? 
Lots of things switch to 'nobody', and this may get logged.

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>

[Jonathan Berry]

On Tue, 1 Mar 2005 10:26:52 -0500, Matthew Miller <mattdm(a)mattdm.org&gt; wrote:
>  On Tue, Mar 01, 2005 at 09:19:01AM -0600, Aleksandar Milivojevic
> wrote:
>  > >"if this is a 64 bit machine... the nfs nobody user has UID of -1...
>  > >which is a lot on 64 bit"
>  > Good thing nobody logs in as nobody :-)
>  > Or is there anybody?
>  
>  Lots of things switch to 'nobody', and this may get logged. 
A quite interesting discussion.  Something must get logged at some point:
$ ll /var/log/lastlog
-r--------  1 root root 1254130450140 Mar  1 20:01 /var/log/lastlog
$ ll -h /var/log/lastlog
-r--------  1 root root 1.2T Mar  1 20:01 /var/log/lastlog
Now I wish I had a 1.2 Terabyte disk in my laptop ;).  Using "ls -hs"
shows the actual size to be 52 kB.
Actually this is very close to the value reported by the OP, so
perhaps he also has a 64-bit machine.  It has sort of been suggested,
but for the OP, the "du" program is very useful for telling you how
much space things take up.  I especially like "du -hs *" which tells
you the size of each of the directories in the current directory. 
Also, check out "df" and "df -h"  Note that all of these should be
run
in a terminal.
Lastly, if you are trying to use Ghost, then you actually may not be
able to go from a 160 GB disk to a 36 GB disk.  Ghost, as far as I
know, creates an image of the disk, which is a direct binary copy. 
You should be able to do this on a partition-by-partition basis if the
partitions are the same size, but I would still be careful.  Perhaps a
better choice would be to boot to the rescue CD and simply mount the
partition to copy from and to copy to and just copy the files with "cp
-a".

Jonathan

[Jeff Vian]

On Tue, 2005-03-01 at 20:30 -0600, Jonathan Berry wrote:
>  On Tue, 1 Mar 2005 10:26:52 -0500, Matthew Miller
> <mattdm(a)mattdm.org&gt; wrote:
>  > On Tue, Mar 01, 2005 at 09:19:01AM -0600, Aleksandar Milivojevic wrote:
>  > > >"if this is a 64 bit machine... the nfs nobody user has UID of -1...
>  > > >which is a lot on 64 bit"
>  > > Good thing nobody logs in as nobody :-)
>  > > Or is there anybody?
>  > 
>  > Lots of things switch to 'nobody', and this may get logged.
>  
>  A quite interesting discussion.  Something must get logged at some point:
>  $ ll /var/log/lastlog
>  -r--------  1 root root 1254130450140 Mar  1 20:01 /var/log/lastlog
>  $ ll -h /var/log/lastlog
>  -r--------  1 root root 1.2T Mar  1 20:01 /var/log/lastlog
>  Now I wish I had a 1.2 Terabyte disk in my laptop ;).  Using "ls -hs"
>  shows the actual size to be 52 kB.
>  Actually this is very close to the value reported by the OP, so
>  perhaps he also has a 64-bit machine.  It has sort of been suggested,
>  but for the OP, the "du" program is very useful for telling you how
>  much space things take up.  I especially like "du -hs *" which tells
>  you the size of each of the directories in the current directory. 
>  Also, check out "df" and "df -h"  Note that all of these should be
> run
>  in a terminal.
>  Lastly, if you are trying to use Ghost, then you actually may not be
>  able to go from a 160 GB disk to a 36 GB disk.  Ghost, as far as I
>  know, creates an image of the disk, which is a direct binary copy.  
This explanation of ghost is not quite correct.  

dd would create an exact binary copy, byte for byte and can only be used
to copy to a drive/partition of the same size or larger.  It also would
have issues with wanting to resize partitions.

Ghost, OTOH creates a copy of the *_data only_*, and stores the
partition size/type information as well.  

Thus, you, in fact, may not be able to go from a 160gb disk to a 36gb
disk, but that would be due to space occupied by the data and not by
virtue of the original drive/partition size. 
When you use Ghost to create and restore the image it will tell you both
the partition size and the data size so you know what your choices are.
Partition size is adjustable, data size is not.

>  You should be able to do this on a partition-by-partition basis if
> the
>  partitions are the same size, but I would still be careful.  Perhaps a
>  better choice would be to boot to the rescue CD and simply mount the
>  partition to copy from and to copy to and just copy the files with "cp
>  -a".
>   
This may be a good choice.

>  Jonathan
>

[Jonathan Berry]

On Tue, 01 Mar 2005 21:00:26 -0600, Jeff Vian <jvian10(a)charter.net&gt; wrote:
>  On Tue, 2005-03-01 at 20:30 -0600, Jonathan Berry wrote:
>  > Lastly, if you are trying to use Ghost, then you actually may not be
>  > able to go from a 160 GB disk to a 36 GB disk.  Ghost, as far as I
>  > know, creates an image of the disk, which is a direct binary copy.
>  
>  This explanation of ghost is not quite correct.
>  
>  dd would create an exact binary copy, byte for byte and can only be used
>  to copy to a drive/partition of the same size or larger.  It also would
>  have issues with wanting to resize partitions.
>  
>  Ghost, OTOH creates a copy of the *_data only_*, and stores the
>  partition size/type information as well.
>  
>  Thus, you, in fact, may not be able to go from a 160gb disk to a 36gb
>  disk, but that would be due to space occupied by the data and not by
>  virtue of the original drive/partition size.
>  When you use Ghost to create and restore the image it will tell you both
>  the partition size and the data size so you know what your choices are.
>  Partition size is adjustable, data size is not. 
Ahh, thanks for the correction.  Remind me not to try to explain
things I have no experience with or knowlege of : ).  I assumed an
"image" was just that, similar to an iso image.

Jonathan