Re: ooops

[Scott Wood <treii28@xxxxxxxxx>]

eeek - use a pager to look at files that huge!  Usually 'less' (if
available) is more than sufficient.  I am presuming you are new so I
won't attempt inflicting 'vi' bindings on you yet, but it also works
well on big files.  On some systems, you might not find less, but
'more' will usually be on most unixes nowadays.

Scott

P.S. 'b' and 'g' come in very handy in less (which is used on most
linux's for man pages too)


--- Zachary Florian <icthusianz@ameritech.net> wrote:
> okay so i just decided to to do that 'du -s *' thingy... something
> odd the
> root directory had 1.3gigs to it's behalf, anyhow i entered that
> and tried
> the 'du -s *' thingy again, only have one directory in there, has
> like 4K
> locked up... did 'ls -als -h' and when my eyes finally realized one
> of the
> letters was G not K i found that the file .xsession-errors was
> approx 1.3G
> in size... i'm gonna assume it'd be wise of me to possibly find a
> way to
> read that, when i typed in 'emacs .xsession-errors' it wouldn't
> load (not
> enough buffer)... what should i do? obviously delete
> '.xsession-errors' but
> how do i make sure this doesn't happen again... how do i safeguard
> myself
> against the error (or reconfigure correctly) if i don't really know
> what the
> error is/was? do i just delete, run X and then check the file the
> next time
> to see if it's there again?
> 
> 
> >usually the first place that I look when out of filespace (unless
> of
> >course the system was close to full to begin with) is the /var
> >directory tree.  First, /var/log then perhaps /var/spool
> >
> >If there is an error going on somewhere, it can fill logs up in a
> >hurry.  Also, most distributions 'rotate' logs every so often so
> you
> >might find old versions (.1, .2, .3, .4 extensions).  If you have
> no
> >desire to keep old logs, you can delete them.  (of course, if you
> >didn't expect to be out of space, you might want to 'look' at them
> >first or at least save them somewhere to look at later.  If
> something
> >is generating errors out of control, that is your best way to find
> >out what)
> >
> >The /var/spool is the second place to look for two or more
> >possibilities.  mail and lp stuff show up there.  If you get a
> mail
> >bomb or perhaps set up sendmail incorrectly so that some message
> is
> >endlessly crashing in a loop, you can get really huge files or
> >perhaps tons of failed delivery messages showing up in there. 
> Also,
> >most system processes on most distributions get mailed to root,
> and
> >sometimes people don't know that.  (when I started work with a
> small
> >ISP once, the root mailbox was over 4.5 meg in size and dated back
> >two years!!!)
> >
> >Same with print jobs.  If for some reason a print job was sitting
> in
> >the queue and there was some sort of error delivering it to the
> >printer, the system will retry the printing of the file every so
> many
> >seconds.  This can both fill up the printer log and occasionally
> >create temporary files in the process of trying to print the file.
> >If a filter explodes, it can also create large files in there.
> >
> >The last place to look is /tmp and perhaps /usr/tmp where the
> system
> >puts large files.
> >
> >As some helpful utilities to 'seek out' huge files, you might try
> >using the 'find' command (take a look at the manpage for how to
> >specify size parameters) or 'du'.  If you have enough overhead in
> the
> >swap, you can even do something like ' du / | sort -nr | less ' -
> but
> >expect a lot of disk grinding for that one!  Perhaps your best bet
> is
> >to just go to the root directory (/) and do a du -s *.  find the
> >large trees and move in and do du -s * again and so on.  Learning
> the
> >basic directory sizes of the various system trees comes in handy
> for
> >chasing these things down and also for avoiding such problems in
> the
> >future (Read below).
> >
> >Once you learn what directory sizes and needs are, I usually
> >recommend that users partition off their harddrive accordingly so
> >that programs on one partition don't 'overrrun' programs on
> another
> >causing system failures or stoppages for no good reason.  Some
> >schemes I have seen would include various combinations of the
> >following:
> >
> >/var/log (system logs)
> >/var/spool (various queues and mail)
> > possibly including:
> >  /var/spool/mail
> >  /var/spool/lp
> >
> >although I have not done it, some recommend using a seperate
> >partition for /usr from root.  (I play with lots of 'test' kernel
> >mods and such and still wanna be sure that I have access to the
> /usr
> >partition during the early stages of boot-up just to be sure, so I
> >don't use this one)
> >
> >other recommended partitions might include:
> >/tmp (temporary workspace)
> > and occasionally
> > /usr/tmp (some programs like to use this instead of tmp)
> >/home (user directories)
> > I actually break mine down to level of users.  This really comes
> > in handy with some of my apache modules too where you can set
> > permissions 'per filesystem'.  i.e.
> > /home/u1 (primary users)
> > /home/u2 (secondary users)
> > /home/f1 (ftp users)
> > /home/s1 (system administrator(s))
> >   ... etc ...
> >
> >/usr/X11R6 (X windows resources)
> >
> >/usr/local (usually 'user added'
> > on most distributions)
> >/usr/local/etc (obsolete?)
> >  this is one I used to use when apache used to like to sit in
> there
> >
> >and one I like to use a lot is:
> >/usr/src
> >
> >I actually set that one up on a seperate drive entirely so that it
> is
> >easy to get at the kernel and/or package sources I am working on
> no
> >matter what I do with that system.  Eventually, I will probably
> set
> >that up on a jaz 2gB when I get one.
> >
> >This is obviously a bit of overkill, but just some examples.  I
> >currently have three small drives in my system and have it split
> down
> >with:
> >/
> >/var/log
> >/var/spool
> >/tmp
> >/usr/X11R6
> >/usr/local
> >/home/u1
> >/home/u2
> >/usr/src
> >
> >that seems to be sufficient for my needs.  Something else to keep
> in
> >mind, is that you can also do fancy things with the loopback
> device
> >and 'disk image' files.  If you ever wanna have a 'static sized'
> file
> >system but don't wanna repartition, you can create a disk image
> and
> >just mount it as a seperate filesystem - but of course, that is
> >another topic all together....
> >
> >Scott
> >
> >--- Zachary Florian <icthusianz@ameritech.net> wrote:
> >> okay so i did that 'df' command and guess what (yes you already
> >> knew) out of
> >> 2047792 (i'm assuming bytes) of space i had none free... 100%
> >> used... so i
> >> set upon my quest to find the evil gluttonous file before it
> >> screwed it up
> >> again somehow... i checked /home/$USERNAME like you suggested,
> >> nothing
> >> unnaturally big... merely a few thousand (once again bytes i
> hope)
> >> in each
> >> file... so then i checked in /var/log once again nothing, i do
> not
> >> seem to
> >> have a /etc/vdm or an /etc/gdm because i could not find them...
> >> also merely
> >> for the heck of (cause i didn't know what else to do and i
> thought
> >> maybe
> >> it'd make sense...) i did an 'ls -als' at the furthest back 'cd
> ..'
> >> i could
> >> do... once again nothing overly large, merely a few near
> 4-5000...
> >> the
> >> reason i thought it might help was because i figured the file
> would
> >> be in
> >> one of the directories and so that directory would have to be
> >> pretty big if
> >> it housed the file... i can't really think of anything, so i'm
> >> going to turn
> 
=== message truncated ===


=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com