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