Мой сервер redhat дает сбой примерно каждые три недели в 4:15 утра по воскресеньям. (ну, это было в воскресенье, последние два были утром в четверг, в 16:15). Глядя на журналы (mysql, httpd, messages), нет никаких подсказок, почему. Кажется, они просто останавливаются.
Я запустил небольшой скрипт, чтобы снимать показания памяти каждые 15 минут, и он тоже останавливается (с нормальными показаниями) в это время.
Сервер удален у поставщика, поэтому я могу получить к нему доступ только через Интернет. Я использую Plesk.
Похоже, проблема связана с установленным заданием или чем-то еще. Я ничего не вижу в crontab.
Итак, мой вопрос ... Был ли у кого-нибудь еще это и может ли он дать совет? В противном случае.
Кто-нибудь знает способ получить более подробный журнал, чем тот, который предлагается файлом сообщений? Я думал о программе записи в стиле черного ящика или, может быть, о чем-то более простом, как вариант где-нибудь, чтобы повысить уровень отчетности в журнале сообщений.
Спасибо
Вы можете включить дампы ядра, которые будут копировать системную память в файл при сбое сервера.
Следующая проблема заключается в том, что делать с файлом coredump ... Если у вас есть кто-то, кто знает все о GDB, он может что-то с этим поделать ... или вы можете использовать команду "strings", чтобы выгрузить все текста из файла coredump, и, возможно, вам удастся что-нибудь найти.
это время, когда запланированы задания cron.daily, поэтому я бы заглянул в /etc/cron.daily, еженедельно или ежемесячно в качестве первых подозреваемых
вы можете установить поверх, который будет записывать снимки процессов каждые 10 минут
в качестве альтернативы вы можете установить psacct и использовать accton и lastcomm, чтобы увидеть, что выполняется
включение аудита также возможно, см. auditd (8)
войдите в другой ящик, который хорошо подключен, запустите screen, ssh на сервер и закройте kern.log, daemon.log, syslog, сообщения в отдельных окнах экрана. (Ctrl-A, c для создания нового окна, Control-A, D для отсоединения, screen -r для возобновления)
когда сервер снова блокируется, у вас должна быть последняя часть журналов в сеансе экрана, даже если они не были правильно сброшены на диск, когда машина зависла.
Если вы подозреваете панику ядра или упс
kernel.panic = 5 kernel.panic_on_oops = 5
в вашем sysctl.conf или аналогичном файле будет ждать 5 секунд, возможно, позволяя дискам очиститься, а затем перезагрузится.