[SOLVED] update centos

[sayres]

[code]
[sayres@centos ~]$ sudo yum --disablerepo=\* --enablerepo=rpmforge install flash-plugin.x86_64
[sudo] password for sayres:
Loaded plugins: fastestmirror, priorities, refresh-packagekit
Loading mirror speeds from cached hostfile
* rpmforge: apt.sw.be
Setting up Install Process
Package flash-plugin-11.0.1.60-0.1.el6.rf.x86_64 already installed and latest version
Nothing to do
[sayres@centos ~]$

[/code]

I want to install centos 6 Agane.
Perhaps the problem is resolved.
What is your suggestion?

[pschaff]

I have no real basis for judging if a reinstall will help. If it is a hardware issue it will not. If it is a software problem with 3rd party packages then I would expect a clean install to fix it, but then reinstalling the same set of 3rd party packages might well replicate the problems.

[sayres]

I solved my problems with the reinstall centos....
:-)

[pschaff]

Thanks for reporting back. I hope it stays fixed. Marking this thread [SOLVED] for posterity.

[tektris]

Even though this thread is old and has been marked as solved; I found another solution that may help someone:

I checked the /var/log/messages and noted that each time the server crashed it was due to an out of memory error, which then invoked the OOM Killer (out of memory).

This sometimes will kill processes that will cause your server to freeze. My research proved that the best possible way to resolve the issue was to figure out what was the root cause of the OOM. However upon discovery of my root cause, I could not readily fix, but I did not want the OOM killer to freeze my entire system, hence I had to make a change to /etc/sysctl.conf:

# Prevent OOM killer (Out of Memory) which causes the server to crash
vm.overcommit_memory = 2
vm.overcommit_ratio = 10

PLEASE NOTE:
This is a temporary fix and is not recommended for production environments, because if an out-of-memory condition does present itself, there could be unexpected behavior depending on the available system resources and configuration. This unexpected behavior could be anything from a kernel panic to a hang depending on the resources available to the kernel at the time of the OOM condition.

For some environments, these configuration options are not optimal and further tuning and adjustments might be needed. Configuring HugePages for your kernel can assist with OOM issues depending on the needs of the applications running on the system.

[Whoever]

vm.overcommit_ratio = 10

I would be very surprised if that is what you really want.

It might be the right number, but only if you have a huge amount of swap . Llarge amounts of swap are not recommended these days because of the increased disparity between access speeds of hard drives and RAM.