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@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@mavis root]#
to verify that cron.daily was working. It was. Then I tried executing (as root)
[root@mavis root]# /usr/sbin/tmpwatch 240 /tmp
and I *still* have a bunch of old files in /tmp
[root@mavis root]# find /tmp -ctime +10 | wc -l
613
[root@mavis root]#[root@mavis root]# find /tmp -ctime +30 | wc -l
461
[root@mavis root]#[root@mavis root]# find /tmp -ctime +100 | wc -l
300
[root@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@mavis root]# find /tmp -ctime +141 | wc -l
0
[root@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