On Sun, Jun 13, 2004 at 04:53:50PM +0200, Rud Holmgren wrote:
>
> Having just upgraded my fc1 installation to fc2
> I experience that the CPU is constantly loaded
> at about 20% average. On the system monitor applet
> the load appears as spikes when using a 0.5 sec
> update interval. The spikes are neither regularly
> spaced nor equal in height.
.....
> My guess is that some process is started regularly
> that eats up a lot of resources and then dies. I
> have tried catching this - without any luck.
First unplug the net (5, 10, 20 min or so) and watch if this changes
things. This might be simpler than trying to think about dealing with
open services and some of the current httpd attacks. Some connections
like an open mail relay will do just what you are seeing.
Inspect log files:
ls -ltr /var/log
tail -f /var/log/messages
tail -f /var/log/anything-interesting
Inspect the list of services and turn extra stuff off:
chkconfig --list | grep on
Look in cron's list of tasks for old forgotten crontabs.
Look at /etc/inittab and /var/log/* for broken init stuff/hints
If init finds that it is continuously respawning an entry more than 10
times in 2 minutes, it will assume that there is an error in the com-
mand string, generate an error message on the system console, and
refuse to respawn this entry until either 5 minutes has elapsed or it
receives a signal.
It might be useful to run the equivalent of "sar -A 5 5" for an
interesting period of time and try to learn something about what is
going on. Is it disk, processes, network? Compare and link this with
multiple copies of ps -eflACH (or sa) look at the pile and see if
something pops out and matches your spikes.
Watch LEDs on network links. If they pop up active and match
the load snoop some packets.
Install and turn on accounting.
The kernel maintains an accounting information structure for all pro-
cesses. If a process terminates, and accounting is enabled, the kernel
calls the acct(2) function to prepare, and then append, a record for
this process to the accounting file. acct(2), sa(1)
Tricks like this might help (if the process exits):
# sa > /tmp/sa1; sleep 20
# sa > /tmp/sa2
# diff /tmp/sa2 /tmp/sa1
1,2c1,2
< 11329 93035.79re 22.68cp 0avio 1907k
< 68 2320.79re 6.19cp 0avio 2377k ***other*
---
> 11328 93035.79re 22.68cp 0avio 1907k
> 69 2320.80re 6.19cp 0avio 2352k ***other*
103d102
< 2 0.01re 0.00cp 0avio 662k sa
Or perhaps to make the point more clear, note how the count for "diff"
changes each time.
# sa > /tmp/sa2; diff /tmp/sa2 /tmp/sa1 | grep diff
< 21 0.03re 0.00cp 0avio 1190k diff
> 5 0.00re 0.00cp 0avio 1018k diff
# sa > /tmp/sa2; diff /tmp/sa2 /tmp/sa1 | grep diff
< 22 0.03re 0.00cp 0avio 1194k diff
> 5 0.00re 0.00cp 0avio 1018k diff
# sa > /tmp/sa2; diff /tmp/sa2 /tmp/sa1 | grep diff
< 23 0.03re 0.00cp 0avio 1190k diff
> 5 0.00re 0.00cp 0avio 1018k diff
Since it is only 20% lets rule out setiathome.
Good luck....
--
T o m M i t c h e l l
/dev/null the ultimate in secure storage.
