Robert wrote:
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.
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. :-)
