Re: ooops

["Zachary Florian" <icthusianz@xxxxxxxxxxxxx>]

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
>> 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
>