Re: ooops

[Scott Wood <treii28@xxxxxxxxx>]

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
> in for now... i'd like to play with this as much as possible to see
> if i can
> get it figured out (with all your wonderful help, KLUG you rock!)
> at least
> maybe prior to Tuesday... if all else fails and i just can't figure
> it out
> i'm gonna be bringing down my machine... :)
> 
> 
> 
> >> It's like Adam said: an error log file has likely filled up your
> hard
> >> drive.  Use the 'df' comand to see how much of your drive is
> being
> >> used.  If you see 100% then you'll need to seek and destroy this
> file.
> >> It will likely be in your home directory (/home/$USERNAME). 
> When you
> >> boot linux as single you are automatically logged in as root. 
> Just go
> >> ahead and cd to /home/$USERNAME ($USERNAME is whatever the name
> of
> >your
> >> user account is...) and type 'ls -als'.  This will show you all
> the
> >> files in the directory as well as their sizes.  Most error log
> files
> >> should be pretty small (DEFINITELY less than 1 MB).  The
> offending
> >file
> >> should stick out like a sore thumb.  If the files seem to go by
> to
> >fast
> >> you can use SHIFT+PAGE UP to scroll back up the terminal or you
> can
> >use
> >> the wonderful pipe: ls -als | less, which will pipe the output
> from ls
> >> into a convenient scrolling buffer.
> >
> >It might be a good idea to check in /var/log and /etc/xdm or
> /etc/gdm
> >as well for swollen log files.
> >
> >
> >
> 
> 


=====

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