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