forum.lissyara.su

Сервер "заклинило". Попытался убить висящие процессы - не убиваются (т.к. у них стоит статус D).
Попробовал сделать reboot - сервер завис (возможно на этапе завершения, процессы ведь не убиваются).
Помогла перезагрузка кнопкой.
В логах пусто.

Как искать причину?
Как убить процесс, если он не убивается по kill -9?

Никак.
Сталкивался с подобным, когда подвисал намертво mpd. Чинилось выпиливанием из ядра

Очень странно.
Даже не могу поверить, что FreeBSD может так упасть капитально и без возможности восстановления.

Упасть может любая ОС. Какое восстановление? У вас затёрлись файлы, после подвисшего процесса или форматнулся раздел?

может породить схожую проблему http://ithappens.ru/story/184

Упасть может любая ОС. Какое восстановление? У вас затёрлись файлы, после подвисшего процесса или форматнулся раздел?

Есть еще такое понятие как простой - это значение тоже очень важно.
Ладно зависла ОС. Но ведь она не перегрузилась удаленно.
Ладно она раз не перегрузилась. Но что делать если это будет каждый день? Или 10 раз в день?
Потому я еще и спрашиваю: как искать причину? Как предотвратить подобное?

может породить схожую проблему http://ithappens.ru/story/184

Примерно так и происходит - надо человеку из ДЦ идти к стойке и руками перезагружать (а это не всегда быстро).

И еще вопрос: как можно смоделировать подобное зависание?

как искать причину?

Настраивать логи, они же по умолчанию не всё показывают, и включены не все.
Ставить мониторинг, чтобы по графикам выяснить зависимость.

Это все общие слова.
Что именно надо искать в логах (т.е. что добавить в логирование)?
Что именно мониторить? Это рабочий сервер с клиентами - он всегда не очень равномерно нагружен. Т.е. зависимость можно выяснять очень долго - что совсем не будет радовать клиентов.
Должен же быть механизм для поиска подобных проблем (я надеюсь).

И для меня остается загадкой почему FreeBSD не дает убить процесс, очень странно. Я бы еще понял при полном зависании системы. Но ведь я смог пойти по SSH, смог выполнять различные команды - т.е. система была еще жива.

Это все общие слова.

Это не общие слова. Это направление к приложению усилий. Смотрите, что у вас повисло, читайте, какие логи может генерировать данный демон и сопутствующие службы. Включайте всё, анализируйте.

И для меня остается загадкой почему FreeBSD не дает убить процесс, очень странно.

Есть ли система, в которой можно гарантированно прибить любой процесс?

Смотрите, что у вас повисло, читайте, какие логи может генерировать данный демон и сопутствующие службы.

Опять общие слова. Пример ситуации: программа состоящая только из "hellow world" зависла. И какие логи моей программы тут помогут?
Проблема не в процессах, проблема в самой ОС. Все процессы повисли. Новые процессы запускаются, а старые не завершаются.

Есть ли система, в которой можно гарантированно прибить любой процесс?

Если система не зависла, то вроде как да - FreeBSD
Первый раз наткнулся на иное поведение и удивляюсь.
Да и почему должно быть обратное? Если система жива, значит одна должна уметь убить процесс. Иначе система уже не жива. Но тогда как понять что с системой?

icb писал(а):

Есть ли система, в которой можно гарантированно прибить любой процесс?

Если система не зависла, то вроде как да - FreeBSD

Не правда! Даже на работающей системе я натыкался не мало раз, когда процесс никак не убивался. Более того, подвисал даже ребут системы. Наблюдал на FreeBSD, Solaris

емнип флаг D это значит что программа находится в состоянии ожидания ввода вывода
могу предположить что это состояние полностью блокирует выполнение кода программы, даже служебного, отвечающего за обработку сигналов.
еще, тока пришло на ум, мона попробовать /bin/kill вместо встроенного в шелл kill
из тяжелой артиллерии можно поковырять код планировщика, хальтнуть систему и посмотреть что тогда творилось в ядре, сменить планировщик
с реализацией механизма сигналов во фре я не знаком, а жаль

FreeBSP писал(а):емнип флаг D это значит что программа находится в состоянии ожидания ввода вывода
могу предположить что это состояние полностью блокирует выполнение кода программы, даже служебного, отвечающего за обработку сигналов.
еще, тока пришло на ум, мона попробовать /bin/kill вместо встроенного в шелл kill
из тяжелой артиллерии можно поковырять код планировщика, хальтнуть систему и посмотреть что тогда творилось в ядре, сменить планировщик
с реализацией механизма сигналов во фре я не знаком, а жаль

Не, беспонту. Процессы со статусом D убиваются только ребутом. Увы, но это так, причем не только во фряхе, линупс тоже этим "болеет"...
Кстати, в 9.0 есть бага в ядре, изза которой процессы находятся в состоянии D...
http://www.freebsd.org/cgi/query-pr.cgi?pr=166340

они помирают естественной смертью за время порядка нескольких часов
по крайней мере у меня так когда то было

FreeBSP писал(а):они помирают естественной смертью за время порядка нескольких часов
по крайней мере у меня так когда то было

Это смотря как залипнет)