Michael Best wrote:
> A reformat reinstall is nothing more than erasing the disk and
> starting over, give or take some log files.
>
> *) Erase all files associated with the application and reinstall, test
> *) swap space is being corrupted? turn off swap
> make swap with the check for bad blocks option, turn swap back on
> *) Run harddrive diagnostics perhaps the harddrives are going bad
> *) Run memtest+, if you can do this as an overnight burn in
> *) Perhaps Steam is the problem, who knows?
First off, I'd set up a way to recover the system from a time before it
stopped working correctly. Mirroring the files to another disk is
probably the fastest way, then you could just boot off KNOPPIX and rsync
the backup files over what's there. If you were running from within
VMware, you could just schedule snapshots and revert to a previous
snapshot of the system when it was working properly. Restoring from
tape is too slow and a pain to do, not something you want to get stuck
doing every couple weeks, much easier and faster to just rsync off an
extra disk or another computer.
If possible, I would repartition the system with two "root" partitions
called "/" and "/r2" and "/r2" would just be an rsync backup of "/".
You would set up LILO or GRUB entries to be able to boot off /r2, plus
you need to modify /r2/etc/fstab since the root partition is different
to "run" on that copy. Say for example you sync / -> /r2 daily, and the
day the app stops working, you just reboot the system into /r2 and the
system is probably working again, then sync /r2 -> /. I have used this
approach a lot so that I could install a newer OS on /r2 but leave the
old OS on / in case there was a problem getting any custom applications
to work I could just reboot to the old OS and it's no problem. Some
people have complained that it "wastes disk space" so lately I split the
OS into "/" and "/usr/share" then when I want to install a newer OS I
move /usr/share to a loop filesystem on /home for example and the
/usr/share partition becomes /r2. It's a bit more complicated but it works.
Offhand, I'd burn a stresslinux CD and try memtest86 and the appropriate
versions of cpuburn to see if anything weird happens:
http://www.stresslinux.org/
Then still running off the CD, I'd try the "mkswap -c" and "e2fsck -c
-f" on all of the filesystems, assuming you're using ext2 or ext3
filesystem--usual disclaimer to BACK UP your system and so on. Maybe
Steam is getting its data out of the "wrong place" w.r.t. the Linux
kernel like reading from fs buffers that may be out of sync as happened
with "dump" but that is just a wild guess because I deleted the original
message and have no idea what Steam is. What follows is just some
general advice to come up with a plan of attack and brainstorming ideas.
I'd avoid having any part of Steam rely on files on an NFS filesystem,
if that is your setup that would be my #1 suspect. If Steam uses any
databases, you might want to run any tools to optimize / fix the tables
periodically.
Try to break down the problem into "layers" analogous to the OSI layers
of what is processing the data where, and then check out the problem at
each "layer" just roughly something like:
application
libraries
database
kernel
filesystem
hardware
network
Those might not be in the "right" order but could give you some ideas.
The goal is to try to isolate and identify what "layer" the problem is
occurring at. I have solved problems where the cause of the problem was
unexpected, like ypbind losing its connection to the NIS server which
seemed like it shouldn't have affected the application but did for some
reason, like the application used certain system calls that ended up
tying into NIS.
--jonathan
