Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Root filesystem 100% full



Technically, if the process isn't running as root and no other processes
(running as root) are writing to disk, then the system should remain up and
running.  When / is ext2fs'd (or whatever) a certain percentage of the disk
space is allocated to only root, so an errant user process can't take down
the system by filling a disk.  df will report 100% but there is some left.
Since root DOES write some logs, it would be prudent to kill anything
unnecessary running as root that is logging and clean out your old logs.




> -----Original Message-----
> From: discuss-admin at blu.org [mailto:discuss-admin at blu.org]On Behalf Of
> Jerry Feldman
> Sent: Monday, June 10, 2002 4:32 PM
> To: discuss at blu.org
> Subject: Re: Root filesystem 100% full
>
>
> I agree here except in to context of temporarily moving those directories
> and restoring prior to shutdown. It is a very dangerous operation.
> I've done this on Unix. It is very dangerous.
> Normally, /etc does not contain very large files, so it is not important.
> /dev sometimes contains some big files if you mistype /dev/null.
> It should
> not contain any real files of any significant seze, just a make file, a
> couple of symlinks.
>
> /bin is sometimes a symlink to /usr/bin, and is normally not critical in
> single user mode. /sbin is very definitely critical. It contains all the
> static binaries. Without it you can't run.
>
> Another condidate is /lib. Again, caution. /lib/modules is used
> during and
> before single user mode.
>
> The bottom line is that if you need to temporarily free up some space for
> your program to continue, you can take a risk, but remember that the risk
> is that your system will become unbootable. You can move /boot/vmlinux if
> it is in the root file system, but the same cautions apply. Depends how
> much you want your program to complete.
>
> IMHO, any program that takes that long to run should have some type of
> checkpoint/restart capabilities. There are exceptions. I am
> working with a
> customer who has code that takes a couple of weeks (on a multi-processor
> system with multiple gigs of memory).
> On 10 Jun 2002 at 16:03, Derek D. Martin wrote:
> > /bin, /sbin, and /etc should *ABSOLUTELY NEVER* be moved off the root
> > filesystem.  Many things which are required to boot the system are
> > located in those directories, and they will not be available to init
> > and its various subprocesses if they are not on the root filesystem.
> > For example, your system will not be able to enable swap at boot time,
> > because the program that does this is /sbin/swapon, which will not be
> > mounted until after swap is normally turned on if it isn't on the root
> > filesystem.
>
> --
> Jerry Feldman <gaf at blu.org>
> Associate Director
> Boston Linux and Unix user group
> http://www.blu.org PGP key id:C5061EA9
> PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss
>
>






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org