DriveSeekError - kill the zombie?
I'm stuck physically far away from a server that has an issue I need to
address, and the person who is my backup is unavailable until later this
week (we are clearly not professional enough, heh).
Anyway a few hours ago, the server started spewing out the dreaded
DriveSeekError errors, and similar IDE bus issues / drive issues. This
was on hdb. As hdb is not vital (it's just a mirror'd backup drive),
the solution would normally be to pull the drive, find a replacement,
and restart.
Of course, I'm not there at the moment and neither is my assistant.
So I'm stuck with a nonresponsive hdb, which was mounted mind you. The
load was climbing over 10.44+ because of an rsync cron job that was
waiting on the drive... I managed to (very slowly) ssh in, kill the cron
job, and order was somewhat restored. Of course the viability of the
server is in question, as at any moment, hdb might have a tantrum on the
ide channel.
I tried to umount it, but of course more errors just started to fill the
log. My temporary and not that great of a solution was to mount
something on top of it (/mnt/aux5) - an ISO image loaded into a loopback
device - so at least anything else trying to access it would just get a
read-only filesystem.
That sort of works for anything in the future, but I think one process
is zombified from before. The load is at 1.00-1.10, and the server's
not doing anything (indeed at this hour in the middle of the night, the
load typically hovers around 0 - no cron jobs are scheduled at the moment).
ps aux reveals no zombied processes, or even dead. There are plenty of
sleeping processes of course... should I just swallow the pain and let
it hover at 1 until my assistant can shut it down and yank the drive?
Note that in the logs, SOMETHING is trying to access hdb, as it is still
periodically spitting out DriveSeekErrors (a few times every half
hour)...
Stupid ide drive causing me lost sleep stress... grrrr...
Reply to: