LINUX.ORG.RU

Поэтапное зависание сервера


0

0

FreeBSD 7.2 STABLE, с обновлениями и пересборкой мира.

Упал ssh. Через какое-то время перестали работать cron и apache где крутился mrtg. Ещё через несколько часов отключились quagga и zebra, машина отвалилась от интернета. Из LAN машина продолжала пинговаться, но больше ни на что не отвечала. После удалённой перезагрузки всё поднялось. В логах вообще никаких сообщений за всё это время, битых файлов на диске не обнаружилось.

Никаких серьёзных удалённых дыр на багтреках не нашёл, от перегрева или скачка напряжения перестало бы работать всё сразу. Что это было?


от перегрева или скачка напряжения перестало бы работать всё сразу.

Не факт. От перегрева часто начинают появляться разнообразные глюки, вылазящие в разных местах и приводящие к очень разнообразным последствиям.

Я подобную картину наблюдал (правда под линуксом), когда внезапно выпал шлейф от единственного жёсткого диска =). Тоже постепенно начали отваливаться разные сервисы, но сетевая подсистема продолжала работать и компьютер пинговался. Может у тебя что-то с диском или соответсвующим контроллером?

Deleted
()
Ответ на: комментарий от Deleted

> Я подобную картину наблюдал (правда под линуксом), когда внезапно выпал шлейф от единственного жёсткого диска =). Тоже постепенно начали отваливаться разные сервисы, но сетевая подсистема продолжала работать и компьютер пинговался.

Интересно. Как бы это отследить...

Может у тебя что-то с диском или соответсвующим контроллером?

Диски там зеркало с hot-spare, контроллер... Ну по логике - вывалился бы он из гнезда, сервак не загрузился бы после принудительного on-off-on. С дисками тоже самое, отвалились бы все три, опять бы ничего не загрузилось.

tx
() автор топика
Ответ на: комментарий от tx

Диски там зеркало с hot-spare, контроллер... Ну по логике - вывалился бы он из гнезда, сервак не загрузился бы после принудительного on-off-on. С дисками тоже самое, отвалились бы все три, опять бы ничего не загрузилось.

Про то, что выпал шлейф - это только для примера. Тот же эффект был бы, если бы например сглючил SATA-контроллер. А перезагрузка могла помочь, если бы он просто сглючил, но не сломался. У тебя все диски подключены к одному контроллеру?

Deleted
()
Ответ на: комментарий от tx

И это, ты смотрел что сыплется в логи во время медленного зависания? Если моё предположение верно, и отвалился контроллер, то в логи должны были тоннами сыпаться ошибки.

Deleted
()
Ответ на: комментарий от Deleted

> то в логи должны были тоннами сыпаться ошибки.

Не факт. Если умер io, то весь printk будет только на экране.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Не факт. Если умер io, то весь printk будет только на экране.

В линуксе сообщения ядра можно читать напрямую из /proc/kmsg (просто cat /proc/kmsg), во freebsd тоже такое должно быть.

Deleted
()
Ответ на: комментарий от Deleted

> И это, ты смотрел что сыплется в логи во время медленного зависания?

Вообще ничего. За сутки ни единого сообщения, кроме ntpdate. Он продолжал писать в лог что у него всё хорошо вплоть до перезагрузки. Соответственно вариант с отваливанием дисков или контроллера не катит - как бы ntpdate записал эти строчки, если с диском были проблемы?

tx
() автор топика
Ответ на: комментарий от tx

Вообще ничего. За сутки ни единого сообщения, кроме ntpdate. Он продолжал писать в лог что у него всё хорошо вплоть до перезагрузки. Соответственно вариант с отваливанием дисков или контроллера не катит - как бы ntpdate записал эти строчки, если с диском были проблемы?

Тогда попробуй память протестить. Поставь на ночь крутиться какой-нибудь memtest86+.

Deleted
()
Ответ на: комментарий от no-dashi

мемори лик с последующей смертью сервисов через OOM-killer, например

Но ведь тогда бы в логах что-нибудь осело...

Deleted
()
Ответ на: комментарий от rjaan

> Не факт что memtest86+ что-то найдет.

Тестили им сервер несколько суток перед установкой на площадку. Врядли в этом дело.

tx
() автор топика
Ответ на: комментарий от tx

> Тестили им сервер несколько суток

Тестили сервер несколько суток

Тестили несколько суток


несколько суток



омфг...

LamerOk ★★★★★
()

нужны сообщения с консоли.

Глюки такого рода много встречал. Условия в дц несколько другие(кстати, проверьте температуру воздуха, винтов и процов), да и глюки бывают такие что проявляются раз в месяц.

Бывает и вообще смешное. Как-то раз сервер стал зависать раз в несколько дней. Опытным путём выяснилось что зависает в 8 утра(тачка вне мониторинга ибо не сильно важна). Оказалось что подвешивал hwclock который запускался по крону. Вот такой новый баг в ядро внесли.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

> Вот такой новый баг в ядро внесли.

Скорее всего эта не Баг, а глючное железо, которое на нашем IT-рынке очень много. Если брать брендовый сервер, например от HP, очень малая вероятность, что он будет подвисать.

Потом ошибки в дистрибутиве... Вроде бы продукты одни те же, а повара разные... ;-))))))

rjaan ★★
()
Ответ на: комментарий от rjaan

Скорее всего эта не Баг, а глючное железо

это баг который был на http://bugzilla.kernel.org/

Если брать брендовый сервер, например от HP

Админил пул из трёх proliant серверов. Серию уже не помню(не сильно новая, правда). Чего стоил один только выход из строя 100% ILO(шесть штук сменили, проблема типа такой: http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627 ... потом hp признал проблему и только спустя пол года исправил firmware). На одном из серверов 4(!) раза меняли платформу. Месяц назад это чудо умудрилось потерять один процессор. Он исчез из ILO и из видимости ОС. Новый админ сказал что недавно проблема повторилась и с новым сервером.

true_admin ★★★★★
()

Что это было?

Deadlock на каком-нибудь редко используемом семафоре или спинлоке. Процессы собрались в очередь на семафор, а его какая-то падла держит и ждёт ещё чего-нибудь, без каких-либо шансов получить.

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.