Linux is the OS you're supposed to be able to run for a month without a reboot. Well, almost.

I'm running RedHat 8.0.94 (Phoebe). I'm pretty happy; linux is a LOT more stable than Win98 or WinXP and is far more scrupulous when it comes to CPU usage. One problem. As soon as I turn on my machine, it begins to slow down. Right after a reboot everything runs fast. Within 24 hours, a change in speed is noticeable. Within 48 hours there is a noticeable pause between the time I press the NumLock key and the appropriate LED changes. Within 72 hours the system is slow enough to be considered unresponsive.

What's it like being slow? Gnome sytem monitor shows that, during the slow periods, RAM usage is around 95%, SWAP around 25%, and CPU around 15% - the same stats I get immediately after I start up. But, unlike immediately after a startup, the hard drive's LED is blinking like crazy and it takes about an hour to log a user in or out.

Fortunately, a simple reboot (not unplugging the computer and plugging it back in but an honest-to-goodness shutdown -r now) restores the system's speed to normal (until it slows down again, that is). Unfortunately, rebooting my machine every 48 hours is extremely annoying, especially when I'm not there to do it.

Help? Anybody?

This seems to be the third case of a
RedHat machine with a memory leak
reported here within a few weeks.

Maybe someone with lots of time should
gather the information of the machines, :)
and compare the running processes (with
their according version numbers) to non
RH machines of a reasonably new patch/
installation level and try to find out what's
pulling them down. ;)

As for your reboots: to avoid a complete
reboot you could try init 1, followed by
init 5 (is that RH's default init?).

Cheers,
Tink

A memory leak, you say? Wouldn't that cause swap usage to rise above 25%? At any rate, it is certainly the best explanation out there. Yes, init level 5 is Redhat's default init level. I'll be able to tell you more in about 48 hours...

Thanks!

Really, it depends :}

Another possible cause for permanent
HDD activity would be the log-daemon
having too much to write, which of course
wouldn't explain why it increases over time.

Cheers,
Tink

It might if there is an infinitely increasing loop.

Do the logs get more entries per hour the longer the machine is running?

I can't possibly know how Redhat has set up their programs to log. How can I determine whether or not this is a log thing? Is there a command that will enumerate all log files, or a command that will enumerate all open inodes?

right, when the system is dragging, run "top" and see who's hogging it.

To compare usage try doing this every few hours:
1) cd to /var
2) run "du -kh log --all"

See if any of the files grow dramatically in size when the system begins to run slower.

Problem:
I tried to run "du -kh log --all"
I got the following output:

36K log/messages
44K log/lastlog
4.0K log/secure
4.0K log/maillog
0 log/spooler
212K log/wtmp
4.0K log/vbox
du: cannot change to directory `log/httpd': Permission denied
du: cannot change to directory `log/samba': Permission denied
4.0K log/cups/error_log
4.0K log/cups/access_log
0 log/cups/page_log
440K log/cups/access_log.1
4.0K log/cups/error_log.1
1.1M log/cups/access_log.2
4.0K log/cups/error_log.2
4.0K log/cups/page_log.1
1.6M log/cups
16K log/scrollkeeper.log
4.0K log/gdm/:0.log
4.0K log/gdm/:0.log.1
8.0K log/gdm/:0.log.2
4.0K log/gdm/:0.log.3
4.0K log/gdm/:0.log.4
28K log/gdm
4.0K log/canna
8.0K log/dmesg
72K log/ksyms.0
4.0K log/cron
8.0K log/boot.log
40K log/XFree86.1.log
40K log/XFree86.0.log
40K log/XFree86.0.log.old
32K log/rpmpkgs
72K log/ksyms.1
0 log/up2date
72K log/ksyms.2
72K log/ksyms.3
32K log/rpmpkgs.1
120K log/messages.1
4.0K log/secure.1
8.0K log/maillog.1
0 log/spooler.1
12K log/boot.log.1
16K log/cron.1
4.0K log/up2date.1
72K log/ksyms.4
72K log/ksyms.5
72K log/ksyms.6
32K log/rpmpkgs.2
100K log/messages.2
4.0K log/secure.2
4.0K log/maillog.2
0 log/spooler.2
16K log/boot.log.2
8.0K log/cron.2
4.0K log/up2date.2
3.0M log

I then copied this output to a text file and saved it under the name "log" in the directory /home/bkay (my home folder) to compare it with future output of "du -kh log --all". Note that I did NOT have to overwrite any files to do this. Later, I ran the command again and got the following output:
4.0K log
I consistently got that output for several other attempts over a five hour period. I found this suspicious for two reasons: 1, I find it unlikely that all my other log files dissapeared and 2, the file named "log" that I created is - you guessed it - 4.0K.
I renamed the file I had created to "mylog" and ran the command again with the following output:
du: `log': No such file or directory
Suing to root and running the command that way had no effect. Renaming "mylog" back to "log", of course, yields the previous output.
So... how can I get a list of my real log files now?

Did you cd /var the next few times you ran the command?
Or did you happen to stay in $HOME? ;)

Cheers,
Tink

'top' is quite handy for finding out who's hogging the CPU. Sometimes my machine will get unresponsive and I'll run 'top' and find out that some program or other is eating up 90% of my CPU. Killing it off almost always solves the problem

Note: The graphical version of 'top' that comes with Gnome 2.0 seems to be kind of unreliable. A lot of times for me it would *not* show the CPU hogging process at the top, or even at all. Running top from a terminal is much better.

Thanks! Yes, changing the directory to /var DOES return the output of "du -kh log --all" to normal. Stupid question, though: how do I know all the logs are in /var/log?

Incidentally, my machine hasn't slowed down yet. I've been babying it a bit, but if nothing happens by tomorrow I'll try running a few more features bundled with Redhat. Hopefully this will narrow down the list of suspect processes.

*grin*

You hope that they are there ;)
But it's just a ... let's call it: tradition?

Cheers,
Tink

As you said Tinkster, there have been many cases of this "memory leak" going around. I remember in one or two of them that the culprit turned out to be xinetd. Although nobody really figured out what exactly in xinetd was behind this, somebody said that after they restarted xinetd the problem seemed to stop.

hmmm.....

Redhat has just announced the release of version 9 of their distribution.
I am, of course, running 8.0.94, which is supposed to be the beta version for 8.1 that Redhat is calling version 9 in order to improve their sales.
The ISO's will be available to the non-paying public in a week. Perhaps the memory leak is fixed in the new version.

Or perhaps I will just switch to Gentoo.