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
