Назад | Перейти на главную страницу

Есть ли какой-нибудь журнал в SuSe Linux, который сообщает, зависает ли машина из-за выхода из-под контроля?

У меня есть сервер SuSe Linux, который зависает из-за неизвестных проблем, и мне интересно, не запускается ли время от времени неконтролируемый процесс, который вызывает его зависание.

Проблема в том, что я не знаю, где его искать после того, как произойдет зависание ... (я не хочу тратить целый день на то, чтобы найти сбежавшего), поэтому мой вопрос: есть ли войти в SuSe, что регистрирует побеги? Если нет, есть ли способ регистрировать такие вещи?

Большое спасибо!

Дополнительная информация поможет. Как вы определяете "зависание"? Предполагая, что у вас есть физический доступ к серверу, вы можете проверить, какие сообщения ядра появляются на экране после зависания. Требуется ли серверу перезагрузка после остановки?

Вы можете отслеживать обычные системные журналы до момента сбоя в / var / log / messages. Если у вас есть открытый сеанс, когда сервер останавливается, просмотрите сообщения драйвера, запустив dmesg.

У вас есть какие-нибудь подробности об оборудовании? Если это оборудование серверного уровня, вы можете проверить журналы оборудования системы, чтобы узнать, есть ли проблемы, такие как плохая оперативная память и т. Д.

У меня открыт случай с SuSE, когда сервер зависает. Они рекомендовали следующие шаги:

  • Подключите последовательную консоль (не очень интересно для зависаний), и у вас iLO ...
  • Перенаправить системный журнал на удаленный компьютер (чтобы вы могли видеть «последние известные слова» - возможно, непосредственно перед тем, как исходная система сможет синхронизировать его с / var / log / messages)
  • Установите KDUMP-Kernel и debug-kernel (дает вам возможность получить ошибку ядра, а не зависать)

Последнее помогло в моем случае - но я смог исправить проблему, запустив определенное действие - затем я получил Kernel-Debug непосредственно перед замораживанием, и с этим SuSE смог предоставить мне PTF (точка-исправление) Ядро, которое устранило проблему.

Но все же вы не описали, при каких обстоятельствах возникает ваша проблема - посреди ночи? Никогда во время работы?

Нет, как правило, нет механизма, который бы сказал, что именно сломалось, вызвав «зависание».

Пока ваша машина работает, используйте top искать процессы, потребляющие слишком много ЦП, free чтобы проверить наличие проблем с памятью (переключение на диск может сделать машину очень-очень-очень медленной) и просмотреть файлы просмотра / var / log, чтобы убедиться, что что-то не так.

ps aux | grep Z отфильтрует зомби-процессы, если они есть.

Чтобы проверить процесс Зомби (несуществующий), мы можем использовать команду.

ps aux|awk '$8 == "Z" {print $0}'

который распечатает только несуществующий процесс.