[56938] in Hotline Meeting

home help back first fref pref prev next nref lref last post

Case 238926 m37-332-4

daemon@ATHENA.MIT.EDU (Camilla R Fox)
Fri Oct 19 08:31:07 2001

Message-Id: <200110191231.IAA09291@red-herring.mit.edu>
To: hotline@MIT.EDU, bobsand@MIT.EDU
Date: Fri, 19 Oct 2001 08:31:05 -0400
From: Camilla R Fox <cfox@MIT.EDU>


I saw this go by, when Ben Blout first mentioned the problem over zephyr.
I wanted to follow up, because we discovered that /tmp was actually on the
/ partition and it would be more usual for it to be on the /var partition.
This is an actual bug, and when I asked Greg about it, we wanted to take
another look at the workstation in question.

Anyhow, Greg's going to get the bug in the Athena release fixed; the
workstation no longer needs fixing, because it looks like the tmp cleaner
(the process which cleans up stray files in /tmp and /var/tmp) deleted
enough of the files to free up some space.

It does seem however, that you both closed the case without doing what
you said that you'd do (the workstation has not been reinstalled),
and you misinformed the user.

It's perfectly acceptable (and under many circumstances recommended)
for users to write data to the local disk of a workstation.  On all unix
machines, /tmp and /var/tmp are world-writable directories, intended for
temporary storage space.  It does happen that users sometimes become
root and accidentally dump large files in other places; we have this
happen from time to time.

An Athena workstation with a full disk is pretty crippled; in many cases
(unlike this one) it doesn't simply fix itself.

-Camilla


home help back first fref pref prev next nref lref last post