clearing out /tmp safely

Robert kerplop at sbcglobal.net
Sat Mar 27 01:48:19 UTC 2004


Jeff Vian wrote:
> 
> 
> Robert wrote:
> 
>> <snipped>
> 
> 
> 
>>
>> [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
> 
> 
> 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 at mavis root]# date
Fri Mar 26 19:24:52 CST 2004
[root at mavis root]# uptime
  19:24:58  up 2 days,  8:03, 13 users,  load average: 0.00, 0.02, 0.00
[root at 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 at mavis root]# uname -r
2.4.22-1.2149.nptl
[root at 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.
-- 
We are sorry.  We cannot complete your call as dialed.  Please check
the number and dial again or ask your operator for assistance.

This is a recording.

  19:45:00  up 2 days,  8:23, 13 users,  load average: 0.01, 0.02, 0.00
      One billion seconds ago it was 18:58:20 CDT Tue 07/18/72






More information about the users mailing list