clearing out /tmp safely

[Jeff Vian]

Robert wrote:

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

That is similar to my history.

I checked the man page for tmpwatch and found this
----------------------------------------------------------------------
       When  changing directories, tmpwatch is very sensitive to 
possible race
       conditions and will exit with an error if one is detected. It 
does  not
       follow  symbolic links in the directories it's cleaning (even if 
a sym-
       bolic link is given as its argument), will not switch filesystems,
        and only removes empty directories and regular files.
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
---------------------------------------------------------------------

Thus it will by design ignore the sockets,  Hmmmmm  ---- system uses 
inodes and does not release them automatically. :-(

Guess on that score I need to do a small script to clean that up. :-)