Hi guys 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 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! TY -- Matt

Why is the default time range for /var/tmp 720 hrs (30 days) and /tmp is 240 (10 days)? Why so much longer for /var/tmp?

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 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!

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

> 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.

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

>Cleaning out /tmp /var/tmp by hand should be unnecessary beyond removing >the >occasional big junk file. > >See: /etc/cron.daily/tmpwatch

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

Tom 'Needs A Hat' Mitchell wrote: > On Fri, Mar 26, 2004 at 11:47:55AM -0600, Robert wrote: > >> 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 > > > .... > >>> Cleaning out /tmp /var/tmp by hand should be unnecessary beyond >>> removing the >>> occasional big junk file. >>> >>> See: /etc/cron.daily/tmpwatch > > > > >> 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 > > > > Are you finding files or directories. > I do see a list of empty dirs that make /tmp look untidy. > An "rmdir /tmp/* " cleans out only the empty ones. > > > There are both directories and files. Here's an example of files: [root@mavis root]# ls -l /tmp | grep -v ^d | grep track -rw-rw-r-- 1 root root 296769536 Jan 26 19:06 track-01.img -rw-rw-r-- 1 root root 521 Nov 14 11:10 track-01.inf -rw-rw-r-- 1 root root 30604268 Nov 14 11:10 track-01.wav -rw-rw-r-- 1 root root 292 Jan 26 19:06 track-01.xinf -rw-rw-r-- 1 root root 504 Nov 14 11:10 track-02.inf -rw-rw-r-- 1 root root 34017020 Nov 14 11:10 track-02.wav -rw-rw-r-- 1 root root 319 Nov 15 12:25 track-02.xinf -rw-rw-r-- 1 root root 511 Nov 14 11:10 track-03.inf -rw-rw-r-- 1 root root 29741084 Nov 14 11:10 track-03.wav -rw-rw-r-- 1 root root 326 Nov 15 12:25 track-03.xinf -rw-rw-r-- 1 root root 502 Nov 14 11:10 track-04.inf -rw-rw-r-- 1 root root 28468652 Nov 14 11:10 track-04.wav -rw-rw-r-- 1 root root 317 Nov 15 12:25 track-04.xinf -rw-rw-r-- 1 root root 493 Nov 14 11:10 track-05.inf -rw-rw-r-- 1 root root 38377628 Nov 14 11:10 track-05.wav -rw-rw-r-- 1 root root 308 Nov 15 12:25 track-05.xinf -rw-rw-r-- 1 root root 501 Nov 14 11:10 track-06.inf -rw-rw-r-- 1 root root 33325532 Nov 14 11:10 track-06.wav -rw-rw-r-- 1 root root 316 Nov 15 12:25 track-06.xinf -rw-rw-r-- 1 root root 501 Nov 14 11:10 track-07.inf -rw-rw-r-- 1 root root 24950060 Nov 14 11:11 track-07.wav -rw-rw-r-- 1 root root 316 Nov 15 12:25 track-07.xinf -rw-rw-r-- 1 root root 511 Nov 14 11:10 track-08.inf -rw-rw-r-- 1 root root 29400044 Nov 14 11:11 track-08.wav -rw-rw-r-- 1 root root 326 Nov 15 12:25 track-08.xinf -rw-rw-r-- 1 root root 503 Nov 14 11:10 track-09.inf -rw-rw-r-- 1 root root 31368668 Nov 14 11:11 track-09.wav -rw-rw-r-- 1 root root 317 Nov 15 12:25 track-09.xinf -rw-rw-r-- 1 root root 506 Nov 14 11:10 track-10.inf -rw-rw-r-- 1 root root 31796732 Nov 14 11:11 track-10.wav -rw-rw-r-- 1 root root 320 Nov 15 12:25 track-10.xinf -rw-rw-r-- 1 root root 504 Nov 14 11:10 track-11.inf -rw-rw-r-- 1 root root 13834508 Nov 14 11:11 track-11.wav -rw-rw-r-- 1 root root 318 Nov 15 12:25 track-11.xinf -rw-rw-r-- 1 root root 512 Nov 14 11:10 track-12.inf -rw-rw-r-- 1 root root 29364764 Nov 14 11:11 track-12.wav -rw-rw-r-- 1 root root 326 Nov 15 12:25 track-12.xinf -rw-rw-r-- 1 root root 297 Jan 26 19:06 track.toc [root@mavis root]# I'm gonna try something for tonight. I'll create a new file, chmod it to 666, touch it to have the same date as track-12.wav above and see if that bugger goes away overnight. Like this: [root@mavis root]# echo "abcdefghijklmnopqrstetc" > /tmp/zzzA-test-file.txt [root@mavis root]# touch /tmp/zzzA-test-file.txt --reference=/tmp/track-12.wav [root@mavis root]# chmod 666 /tmp/zzzA* [root@mavis root]# ls -l /tmp/zzzA* -rw-rw-rw- 1 root root 24 Nov 14 11:11 /tmp/zzzA-test-file.txt [root@mavis root]# touch /tmp/zzzA-test-file.txt --reference=/tmp/track-12.wav [root@mavis root]# Now. I won't even look at the /tmp directory until tomorrow morning. Y'know, sometimes this stuff is more fun to look back at than forward to!

<snipped>

[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

>> >>[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

Y'know, I bet this is gonna turn out to be something really simple that I'm overlooking -- something in the same league as the infamous logrotate problem a few years ago that caused the supply of inodes to dry up in short order.

Jeff Vian wrote: > > > Robert wrote: > >> <snipped> > > > > >> >> [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 > > > > What is your uptime? The system opens some things when it boots that > remain until it gets rebooted, and these may be part of what you are > seeing. Tmpwatch is not supposed to remove stuff that is in use. > > On mine I found over 2000 entries in /tmp/orbit-<user> directory. > These are all socket entries and not actual files so they use no > actual space, but they do consume inodes. The sockets are identified > by the pid using them, and are created everytime you boot, so if you > boot regularly then a lot will get created. > > It seems that tmpwatch is not clearing old unused sockets but actual > files are being kept cleared. (at least for me). > > My uptime took a hit when I replaced hdb earlier this week. [root@mavis root]# date Fri Mar 26 19:24:52 CST 2004 [root@mavis root]# uptime 19:24:58 up 2 days, 8:03, 13 users, load average: 0.00, 0.02, 0.00 [root@mavis root]# The last reboot before that was an extended power outage 52 days earlier. I'm sure I booted 2 or 3 times when I first installed FC1 and obviously once when I installed a new kernel [root@mavis root]# uname -r 2.4.22-1.2149.nptl [root@mavis root]# but other than that, I can't think of any reason to have booted. Since you mentioned it, I noticed all the sockets in /tmp/orbit-* directories but there are plenty of real files in /tmp, too. Y'know, I bet this is gonna turn out to be something really simple that I'm overlooking -- something in the same league as the infamous logrotate problem a few years ago that caused the supply of inodes to dry up in short order.