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