clearing out /tmp safely

[Tom Needs a Hat Mitchell]

On Tue, Feb 17, 2004 at 12:49:31AM -0300, Alexandre Strube wrote:
> Hello Matt
> 
> > I would like to clean out my /tmp partition as per the tip at 
> > http://fedoranews.org/krishnan/tips/tip014.shtml. However, just one small

This tip is heavy handed see below.

> > query. Is there any folders/files in the /tmp directory that shouldn't be
> > deleted? My /tmp currently contains directories such as gconfd-root,
> > kde-root, ksocket-root, lost+found, mcop-root, a number of ssh-*, and
> > files such as crxmlqWMLkc, a number of libGL.la-*, sockets such as
> > mapping-root,..etc.
> > Will all these entries safely be recreated when needed? Just a
> > precautionary measure; I realise it is after all a "temporary" directory! 
> 
> Well, most of these files are from running applications - so, if you cd
> /tmp; rm -rf * 
> you will certainly to restart some of those applications. In fact,
> closing any gnome or kde session, erasing the files and restarting X
> (with a ctrl+alt+backspace) will do the trick.

Cleaning out /tmp /var/tmp by hand should be unnecessary beyond removing the
occasional big junk file.

See:  /etc/cron.daily/tmpwatch

This cron task runs /usr/sbin/tmpwatch for you each day and will do
the right things for most users.  For others the timers may be too
generous if you have lots of temporary files that are not being
cleaned up by their creator.  {the default for /tmp is ten days
(/usr/sbin/tmpwatch 240 /tmp)}.  

If you simply need to tidy up look at the time stamps (ls -l /tmp) and 
pick a good 'short' number. Something like this:

   /usr/sbin/tmpwatch 24 /tmp
   /usr/sbin/tmpwatch 24 /var/tmp

or even something this extreme which is way smarter than the tip.

   /usr/sbin/tmpwatch 1 /tmp
   /usr/sbin/tmpwatch 1 /var/tmp

If you are always cleaning up you might elect to edit the file
to have shorter timers.

Of note if you "rm" a file that is open, active and growing in the
system all you might be doing is removing the link/name that lets you
see the file with ease.  i.e. The file can continue to grow because
the runaway process still has the inode open.  To see what process has
a file open, use "fuser" and perhaps "lsof"


-- 
	T o m  M i t c h e l l 
	mitch48-at-sbcglobal-dot-net