clearing out /tmp safely

Robert kerplop at sbcglobal.net
Fri Mar 26 17:47:55 UTC 2004


Tom Needs a Hat Mitchell wrote:
> 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"
> 
> 

Y'all, I ran across this thread while searching for enlightment 
regarding the complete functional failure of tmpwatch on my FC1 system. 
I have verified that crond is running -- even added an entry to /etc/crontab


[root at mavis root]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
50 10 * * * root run-parts /etc/cron.daily  # <-- added this
[root at mavis root]#





to verify that cron.daily was working. It was.
Then I tried executing (as root)

[root at mavis root]# /usr/sbin/tmpwatch 240 /tmp

and I *still* have a bunch of old files in /tmp

[root at mavis root]# find /tmp -ctime +10 | wc -l
     613
[root at mavis root]#

[root at mavis root]# find /tmp -ctime +30 | wc -l
     461
[root at mavis root]#

[root at mavis root]# find /tmp -ctime +100 | wc -l
     300
[root at mavis root]#

But since I installed FC1 on Nov 7, one would expect that there would be 
   no files over 141 days old in the /tmp directory. And one would be RIGHT!

[root at mavis root]# find /tmp -ctime +141 | wc -l
       0
[root at mavis root]#

So, the question is, what has happened to tmpwatch?  It worked fine in 
RH6.0, RH7.2 and RH7.3 but it sure ain't working in my copy of FC1 and 
I'll be double-damned if I can see what's wrong! Has anyone else been 
here before me?  BTW, this was a clean install of FC1 on a new hard 
drive rather than an upgrade.

Any hints, tips, suggestions or at this point outright giveaways would 
be most welcome.

Thanks,
Robert


-- 
You don't become a failure until you're satisfied with being one.

  11:00:00  up 1 day, 23:38, 13 users,  load average: 0.00, 0.00, 0.00
      One billion seconds ago it was 10:13:20 CDT Tue 07/18/72






More information about the users mailing list