У меня есть 15 идентичных Linux RH 4.7 64-битных серверов. Они запускают кластерную базу данных (кластер на уровне приложения). В некоторых случаях (каждый месяц или около того) случайное поле (хотя и не одно и то же) зависает.
Я могу пинговать коробку и пинг работает. Если я пытаюсь ssh в коробке, я получаю:
ssh_exchange_identification: Connection closed by remote host
SSH настроен правильно.
Когда я иду в серверную и пытаюсь войти в консоль напрямую, я могу переключать консоли с помощью Alt+ Fn, я могу ввести имя пользователя, и символы отображаются, но после нажатия Enterничего не происходит. Я ждал 8 часов один раз, и это не изменилось.
Я настроил системный журнал для регистрации всего на удаленном хосте, и в этих журналах ничего нет. Когда я перезагружаю машину, она работает без проблем. Я запустил тесты HW - все в порядке, и ничего не в журналах. Машины также контролируются с помощью NAGIOS, и нет никакой необычной нагрузки или активности до замораживания.
У меня кончились идеи; что еще я могу сделать или проверить?
Ответы:
Похоже, ваше ядро каким-то образом запаниковало, так что sshd не смог отправить ключи сервера. Возможно, ядро заклинило таким образом, что сетевой стек все еще работал, но уровень vfs был недоступен.
Когда у меня возникли похожие проблемы в системе RHEL4, я настроил службы netdump и netconsole , а также выделенный сервер netdump и syslog для сбора аварийных дампов и информации о панике ядра. Я также установил в kernel.panic sysctl значение 10. Таким образом, когда система паникует, вы получаете и трассировку ядра, и копию памяти в этой системе, которую вы можете проанализировать с помощью утилиты 'crash'.
Вам, безусловно, также будет полезно настроить последовательную консоль для хостов, чтобы вы могли увидеть, как консоль вышла и, возможно, нажала волшебные клавиши sysrq. Кроме того, если вы хотите настроить сеть и у вас есть оборудование, которое ее поддерживает, вы можете использовать IPMI для удаленного выключения, включения, перезапуска и запроса оборудования.
(для чего бы то ни было, RHEL5 имеет аналогичную функциональность с kexec / kdump, только аварийный дамп хранится локально)
источник
Я поставлю доллары на пончики, которые у вас не хватает памяти. Система останавливается, пытаясь выяснить, откуда ее взять. Это может происходить так быстро, что ваш мониторинг не уловит его. Я бы усилил мониторинг, включая удаленное ведение журнала использования памяти. Проверьте в журналах сообщения OOM также.
(Вы можете даже захотеть, чтобы некоторые ssh-окна были открыты для запуска top.)
источник
Для меня это звучит так, как будто у системы недостаточно ресурсов, поэтому процесс, необходимый для серверной части ssh, не может быть распределен.
Фактическое узкое место может варьироваться - из процессов или из памяти - и единственный способ убедиться, это посмотреть журналы и консоль, чтобы увидеть, есть ли там что-нибудь. Возможно, вы захотите настроить сценарий предварительно запускаемых ssh-заданий - по одному для каждой машины - просто чтобы подготовиться в следующий раз, когда это произойдет.
Если это действительно плохо, то вы можете рассмотреть возможность запуска другой оболочки с более встроенными командами, чтобы вы могли исследовать больше без необходимости запуска дополнительного процесса, поскольку это может быть невозможно. Также "tail -f / var / log / *" может быть очень полезным.
Удачи.
источник
Единственный раз, когда я видел что-то подобное, было то, где использовался переключатель KVM и горячая клавиша клавиатуры (например, alt + n) для переключения между серверами. Это происходило не каждый раз, и это влияло на то, что сервер был удален, поэтому это не было сразу заметно. Никаких блокировок не произойдет, если физическая кнопка на самом KVM-переключателе будет использоваться для переключения между серверами. Если бы часто использовалась горячая клавиша, иногда сервер не разрешал новые входы в систему. Существующие сеансы SSH не были затронуты.
источник