SSH недоступен после большой передачи SCP

336
FrankObr

Недавно построен новый сервер i9; это работает Ubuntu 14.

Это происходило 4 раза за последние 2 месяца, и сегодня это могло привести к потере дневных экспериментальных данных.

Вот что случилось:

  • Сервер работал нормально в течение нескольких недель
  • 2 или 3 пользователя одновременно в часы пик
  • Сегодня я инициирую передачу SCP (26 МБ) с сервера на удаленный кластер в другой стране (сервер: Канада, кластер: Германия).
  • SCP достигает 16%, и все связи SSH прекращаются
  • Мой сеанс SSH не отвечает, не может открыть новые сеансы; другие пользователи на сервере видят те же симптомы (не отвечающие сеансы, не в состоянии открыть новые)
  • Файл доступен в кластере, однако он неполный / поврежден

Пинг сервера приводит к: «Узел назначения недоступен»

Чтобы снова запустить сервер, нам нужно перезагрузить физическую машину.

Есть идеи, что может быть причиной и как это исправить? Это происходило 4 раза с момента создания нового сервера и каждый раз, когда это происходило при передаче файлов размером 20-30 МБ с сервера в кластер. Хотя это происходит не каждый раз, когда мы переносим эти файлы, это происходит в 5% случаев.

РЕДАКТИРОВАТЬ: Вот журналы во время недоступности сервера SSH (из var / log / syslog):

Sep 26 09:17:01 snail CRON[34116]: (root) CMD ( cd / && run-parts --report/etc/cron.hourly) Sep 26 10:17:01 snail CRON[34137]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Sep 26 12:36:14 snail rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="763" x-info="http:/ /www.rsyslog.com"] start Sep 26 12:36:14 snail rsyslogd: rsyslogd's groupid changed to 104 Sep 26 12:36:14 snail rsyslogd: rsyslogd's userid changed to 101

Сервер перестал отвечать на запросы в 11:30, и я перезапустил его (физически) в 12:36; так что журналы ничего не говорят нам о том, что произошло в 11:30

** «улитка» - это имя сервера

1
20 МБ очень мало по сегодняшним стандартам. Проверяли ли вы, чтобы большие файлы вызывали сбой последовательно? Что вы видите в системных журналах при возникновении проблемы (`/ var / log / syslog`). xenoid 6 лет назад 0
Самый большой файл, который у меня есть на сервере, - 106 МБ; Я перенес его на немецкий сервер 10 раз без проблем. Что касается логов я добавлю потом на мой вопрос FrankObr 6 лет назад 0
Похоже, `sshd` разбился довольно сильно, по любой причине. NUL-символы в системном журнале тоже не то, что должно произойти, так что, возможно, что-то еще тоже аварийно завершилось. Это может быть поврежденный бинарный файл, плохая память или множество других причин. Что нужно попробовать: получить второй канал к серверу (например, второй `sshd` с другим портом), оставить сеанс на этом канале открытым, посмотреть, сможете ли вы получить` dmesg`, когда произойдет следующий сбой. Также попробуйте перезапустить первый `sshd`. dirkt 6 лет назад 0

0 ответов на вопрос

Похожие вопросы