Недавно мой сервер gentoo начал отключать все сетевые подключения. Поскольку это безголовый сервер, спрятанный в шкафу, у меня нет других способов войти в систему, поэтому я не могу войти, когда это произойдет. Единственный способ восстановить соединение - использовать кнопку сброса и перезагрузить машину.
Нет никаких сообщений, записываемых ядром или где-либо еще, когда это происходит, по крайней мере, не таким образом, который сохраняется на диск для проверки после перезагрузки.
Небольшая информация о системе:
Недавние изменения:
Мне не удалось найти какой-либо закономерности, когда это произойдет, и я не смог определить, умирает ли только сеть, или все остальное тоже останавливается.
Мне нужна помощь в выяснении того, что происходит, поэтому мне нужны советы по решению этих проблем:
Я с радостью приму оба ответа на эти вопросы, предложения относительно того, что может быть не так, или другие вопросы, которые могут приблизить меня к выяснению того, что происходит.
Я удалил brscan4 и brscan-skey, так как это были последние изменения, и у меня все еще происходило зависание, поэтому они исключены из возможных причин. Я также заставил системный журнал помечать журнал каждую минуту, чтобы иметь простой способ отслеживать, когда что-то останавливается на сервере. Оказывается, когда сеть упала, системный журнал сразу же прекратил логирование, так что кажется, что дело не только в сети, это полное зависание системы.
Я также собрал новое ядро, используя инструмент genkernel, поэтому после последнего зависания я теперь работаю на 2.6.38-gentoo-r6, надеясь, что это каким-то образом решит проблему.
Модернизированное ядро не помогло.
Теперь я наблюдал за выводом lm_sensor любых изменений температуры (или чего-либо еще) до зависания, но с последними тремя зависаниями не было заметных изменений температуры до или после зависания, так что эта теория кажется провальной. .
Новой тенденцией стало зависание при просмотре фильмов с использованием MediaTomb в качестве DLNA-сервера. Однако здесь нет прямой связи, так как мы можем смотреть несколько часов без проблем, выключить телевизор, а затем через пару часов, когда мы вернемся и захотим что-то посмотреть, он зависнет через пару минут, три раза в строка. Но последние десять зависаний произошли во время воспроизведения фильма, и многие часы использования в других целях не вызывали никаких проблем.
Пытался переключиться на другую сетевую карту, но без особого успеха.
Наконец-то прогресс? После достаточного количества зависаний настало время для принудительной проверки диска, которая некоторое время шла нормально, но затем снова зависла. Я думаю, это может быть признаком того, что проблема связана с диском или контроллером диска, так как в этот момент в процессе загрузки больше ничего не происходит?
Как и предполагалось, я запустил memtest86 + за ночь, к сожалению, не обнаружив никаких ошибок.
Еще несколько сегодняшних тестов показывают следующее:
/dev/urandom (с помощью dd) на /dev/sda1: Нет проблем/dev/urandom на /dev/sdb3: Нет проблем/dev/sdb3 к /dev/sda1: Нет проблем/dev/sda1 к /dev/sdb3: ВЕСЬ (почти) мгновенно!Я буду тестировать это дальше, тем более что многие зависания, кажется, произошли при чтении только из / dev / sdb3, хотя это, похоже, не вызывает проблемы в этом тесте.
Любые предложения относительно того, что может быть причиной этого, или советы по устранению неполадок, чтобы попытаться выяснить?
Судя по коллективным обновлениям, похоже, что эта ситуация может идти к двум возможностям:
Тесты, которые стоит попробовать:
Вы можете попробовать настроить какой-то процесс регистрации на сервере, который отчитывается, чтобы вы могли определить, жив ли он, когда сетевые соединения разрываются. Это может быть что-то простое, например задание cron, которое wgets удаленный URL-адрес (который затем можно отслеживать в журнале трафика) для настройки удаленного сервера системного журнала, который собирает весь трафик журнала из коробки.
Вы также можете запланировать перезапуск сетевой системы с помощью cron (/etc/init.d/net.eth0 restart примерно раз в час); Таким образом, если вы потеряли соединение из-за какой-либо проблемы с сетевым интерфейсом, его можно было бы очистить перезапуском, не отскакивая от всего окна.
Следующее, что я бы сделал, было бы следующее:
Если сообщения журнала прекращаются при подключении к сети, вероятно, ядро вызывает панику, и вы можете включить дополнительное ведение журнала для этого, чтобы выяснить, почему. Если сообщения журнала продолжаются после того, как сетевое соединение разорвано, значит, проблема в другом. (В этом случае я бы заподозрил неисправную сетевую карту или плохой драйвер, но это только я.) Вы могли бы написать небольшой набор сетевых диагностик, ifconfig/traceroute/ etc. и запустите его из cron в файл журнала; затем, когда у вас есть временные рамки для неактивной сети, вы можете просмотреть журнал, чтобы увидеть, что в это время видит блок.
ОБНОВИТЬ: Поскольку похоже, что проблема заключается в полной панике ядра, следующее, что я попробую, - это настроить lm_sensors и записать вывод sensors команду в лог каждую минуту. Таким образом, вы сможете увидеть, есть ли быстрые или постепенные изменения температуры, которые, как правило, коррелируют с паникой.
Вы можете попробовать переключиться на вторую сетевую карту или также использовать ее, если это еще не сделано. Это поможет идентифицировать или исключить первичный сетевой адаптер и / или связанные с ним кабели, оборудование и т. Д.
Не уверен, должен ли это быть ответ или комментарий.
Ваше описание немного похоже на https://bugs.gentoo.org/show_bug.cgi?id=359671. Хотя некоторые параметры ситуации кажутся другими, особенно. тот факт, что у вас даже нет кабеля, подключенного к realtek, я думаю, это все еще может иметь какое-то отношение к шаткости драйвера realtek, и, вероятно, стоит выкинуть эту идею здесь.
Так что попробуйте занести модули Realtek в черный список.