/tmp/*

S. Bougerolle steveb at creek-and-cowley.com
Sun Oct 27 07:29:22 PST 2002


On Sun, 2002-10-27 at 23:20, Matthias Benkmann wrote:

> There's a difference between avoiding hand-holding and deliberately
> risking someone's data. It doesn't matter if this someone should have read
> the bootscripts or not. There are some things that are simply
> inacceptable. Risking the data of even 1 in a 1000 LFS users just to
> accomodate some people's notion of correctness is one of these things. 

This sounds good - protect the users, any data loss is unacceptable. 
However, I doubt that many people store important data in /tmp without
knowing better - it's not a default storage location in any program I
can think of off the top of my head.  If they go to the trouble of
finding the directory and writing stuff into it they must know SOMETHING
already.  If there were a 10% chance of loss I would agree with you, but
I figure one in a thousand is about the right number and that IS
acceptable and you are being somewhat inconsistent because surely far
more than one user in a thousand manages to trash his system at some
point while setting up LFS, regardless of how you handle /tmp.  Why
worry about this one small point where that might happen?

However, I don't particularly mind one way or another what the book
says.  I was answering what I thought was a specific request on how to
handle /tmp, without much thinking about changing the book.  

I DO think you should stick a brief note in the book about the nature of
/tmp, given that this issue keeps coming up (and wasn't raised by me,
remember).  Not cleaning /tmp may not cause data loss but on any system
people are using in any practical way, it does have the scope to cause
problems and cleaning files is a normal part of Linux start-up.

> Have you had data loss?  I guess no.

The one example I can think of is this: files accumulate in /tmp until
it fills, and since some programs use /tmp for temporary storage, that
causes running applications to freeze.  Most users will respond to that
situation with a reset.  I've seen that sort of thing happen.  Wiping
/tmp at boot time won't always solve it because it can also occur that
one program goes wild and writes an ever-expanding temporary file, but
that does cut the risk considerably.

Anyway, that's just an example and I still don't see that this tiny risk
of data loss (either way) is all-important.  The important point as I
see it is that setting up /tmp and /var/tmp separately, and wiping /tmp
automatically is the RIGHT thing to do because it's consistent
well-defined behaviour (and also somewhat standardized as a bonus).  

Not wiping /tmp at boot is a neutral point to me, but having /var/tmp
and /tmp point to the same area by default would be an unacceptable
shortcut.  Then, if you're going to separate them I think you might as
well go all the way and provide an easy way to keep /tmp clean.

> No, I'm not.  The strategy that works best depends on what you're using
> your system for. There's a big difference between a server running
> unattended (here I agree that /tmp should be wiped at boot) and a desktop
> system shut down every evening with only 1 user.

I did once see an unattended print server that crashed when its
temporary file space filled up with uncountable thousands of job files
that never got deleted for some reason (this was the old lpr daemon,
naturally).  However, I don't know that wiping /tmp at boot would have
solved that because it filled a different partition of /var, IIRC.

Most problems I've had have been with desktop systems which left behind
rubbish in /tmp between reboots. On the other hand, those problems
continue regardless of what we do with /tmp because stuff like GNOME
also likes to write weird proxy files in the user's home directory. 
This cleanfiles business gets very complex very quickly.  In real life,
I not only use TMPFS for /tmp but also have to add extra lines to
various startup scripts (cleanfiles and also the GDM session scripts) to
remove temporary files which get spread across many directories.

(Holiday time!  Canada here I come...)

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