top - 23:54:01 up 24 days, 12:03, 12 users, load average: 30.89, 31.66, 27.11
Tasks: 324 total, 1 running, 323 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.5%us, 1.3%sy, 0.5%ni, 97.0%id, 0.5%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 2596532k total, 2141112k used, 455420k free, 36896k buffers
Swap: 2008116k total, 575756k used, 1432360k free, 848424k cached
Собственно, всё в топе. Машина вся в idle, при этом LA = 30+.
Висит два неубиваемых /usr/bin/convert
Попытки убивать и разбираться с ситуацией привели к тому, что bash через
ssh не грузится. Коннектится и виснет на входе. Два открытых сеанса тоже
висят. Доступен пока только один ssh-сеанс от юзера.
Есть советы, что делать и кто виноват? :D
>Может какой-нить далпайоп-быдлокодер начал конвертить мномегабайтные картинки?
covert висит мой (автогенерация превьюшек по запросу), и процессор, судя по всему, не жрёт. Места на винтах тоже ещё много, успел заметить, пока шелл не повис.
>И как это "неубиваемых"? Вообще никак?
Да. kill -KILL по id процесс, killall -KILL по имени, pkill -KILL по маске имени - пофиг, ноль эмоций. Хотя буковка "D" в статусе, как понимаю, намекает на то, что процесс об самоубийстве задумался. Но дальше - не хочет.
>А если ребутнуть ее?
Удалённая площадка. Провайдер нажмёт reset, а мне потом опять чекать многогиговые mysql-базы...
Так прикол-то в том, что и sy, и wa - около нуля были. Сейчас sy вырос до 10..20%, но wa - по-прежнему около нуля. Кроме того, походу, если машина сама не прочихается, то придётся звонить провайдеру на тему страшной кнопки reset :)
>Хотя буковка "D" в статусе, как понимаю, намекает на то, что процесс об самоубийстве задумался.
Процесс висит на syscall'е. Если syscall завершится, то процессу сразу придет отправленный вами KILL и он завершится. Посмотрите, что написано в demsg (вроде и обычный пользователь может это сделать).
Странно. Не иначе, как диск отвалился, но как же вам тогда там хоть что-то делать удаётся? Какие либо команды, из в памяти не закешированных -- запускаются?
> Походу, Reiser в 2.6.18 не выдержал работу с mysql? :)
Либо так, либо кто-то из пользователей пытался получить root'a
через NULL pointer dereference.
Значит так. Такое я видел, если отвалился сервер CIFS на ранних ядрах. Любое обращение к подмонтированному диску отправляло процесс в D и делало его бессмертным. А LA, собственно, просло пропорционально их числу.
> Значит так. Такое я видел, если отвалился сервер CIFS на ранних ядрах. Любое обращение к подмонтированному диску отправляло процесс в D и делало его бессмертным. А LA, собственно, просло пропорционально их числу. Вывод. Где-то, что-то отвалилось и недоступно.
Я вижу такое постоянно как запускаю kdetv после чего зависают консоли, ps, ls /proc/$KDETVPID/. D означает Deep Sleep, блокировку в системном вызове. Это проблемы с ядром/драйверами(в моем случае с saa7134), кооторые может вызывать и железо. А глючный рейзер фтопку.