/tmp/*

S. Bougerolle steveb at creek-and-cowley.com
Sun Oct 27 08:44:42 PST 2002


On Mon, 2002-10-28 at 00:27, Rui Ferreira wrote:

> > causes running applications to freeze.  Most users will respond to that
> > situation with a reset.  I've seen that sort of thing happen.  Wiping
> 
> Hmmm, windows user behavior...

Perhaps, but unfortunately most users nowadays have been trained by
Windows.

The exact users I had in mind were high school kids who were learning to
use Linux.

> I know that windows is far from being anyone's model here so, if you are
> administrating a system you should be prepared to preform that task every
> now and then. If you're not, the system will fail, the reset responce will
> not work and you get a nice chance to learn about it.

Perhaps.  What's your point?  That this should be done instead of
cleaning /tmp?  Then you are just postponing the problem - when /tmp is
full and you have to decide which files go, how will you do it?  The
user might not even be able to open a terminal window at the time.

However, it is an interesting thought to write a cleanfiles script which
simply checks /tmp and reports if it's dangerously full, or satisfies
some other condition (more than 1000 files with some part of their name
in common - ex 1000 ssh* files).  You could put that in /etc/init.d and
have it ask the user exactly what he wanted to do if there were a
problem.

> And if you're one of those uptime maniacs, the bootscripts will never have
> the chance to do the job for you. There's a chance to learn yet another
> thing - cron jobs.

A cron job could run the same /tmp check.  That's pretty how much how I
do log rotation now, for example.  I'll think about this some more..
after I come back from holidays in a couple weeks :-)

-- 
Steve Bougerolle
Creek & Cowley Consulting

http://www.creek-and-cowley.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list