SSH «Write failed: Broken pipe»: почему сессия обрывается и как это убрать

«Write failed: Broken pipe» появляется в уже открытой SSH-сессии, когда клиент пытается отправить данные, а соединение к этому моменту уже не существует. Технически операционная система сообщает программе, что канал записи закрыт с другой стороны. Обычно это случается после паузы: вы ушли от терминала, вернулись, нажали клавишу и получили обрыв.

Важно, что сама сессия, вероятно, была потеряна раньше. Просто пока данные не отправлялись, клиент об этом не знал. Поэтому ошибка выглядит внезапной, хотя причина накапливалась в тишине: пока канал был неактивен, кто-то на пути забыл о нём.

Самая распространённая: неактивные соединения сбрасывает устройство трансляции адресов. Домашний роутер, корпоративный шлюз или файрвол хранят таблицу соединений и удаляют записи, по которым долго не шёл трафик. Когда вы возвращаетесь, ответы сервера уже не находят дорогу обратно.

Вторая: ограничения самого сервера, например таймаут неактивности в настройках оболочки или в конфигурации sshd. Третья: нестабильная беспроводная сеть, смена сети на ноутбуке, переход между точками доступа, выход из сна. Четвёртая: перезагрузка сервера, нехватка памяти, сработавшая защита. Пятая: слабое мобильное соединение, где потеря пакетов достаточно велика, чтобы SSH счёл канал мёртвым.

Основное лекарство от бездействия: периодически отправлять служебные пакеты, поддерживающие запись в таблице соединений. На клиенте для этого в файле конфигурации задают директиву ServerAliveInterval с числом секунд, например 30 или 60, и ServerAliveCountMax с допустимым числом пропусков. Клиент будет опрашивать сервер и разорвёт связь только после нескольких безответных проверок.

На сервере аналогичные директивы называются ClientAliveInterval и ClientAliveCountMax. Их полезно включать, если вы администрируете сервер и хотите, чтобы для всех пользователей связь не терялась. Подходящие значения зависят от сети: слишком редкие проверки не спасут от сброса, слишком частые создают лишний трафик. Обычно достаточно интервала меньше, чем таймаут вашего роутера или шлюза.

Если keepalive не помог, значит проблема глубже. Проверьте, не переключается ли сеть: на ноутбуке при выходе из сна Wi-Fi может переподключиться и сменить адрес, и тогда открытые сессии неизбежно рвутся. Посмотрите, не совпадают ли обрывы по времени с работой энергосбережения адаптера.

Для мобильной или нестабильной связи имеет смысл использовать инструменты, которые переживают обрывы: терминальные мультиплексоры, например tmux или screen, запущенные на сервере. Сессия продолжает работать после разрыва, а вы просто подключаетесь заново и возвращаетесь в тот же терминал. Для сетей с потерями существует и отдельное ПО, рассчитанное на нестабильные каналы.

Признак серверной причины: разрывы происходят у нескольких пользователей и в разных сетях, а в журнале сервера видны перезапуски демона, срабатывания защиты или нехватка ресурсов. Тогда стоит смотреть системный журнал и нагрузку.

Отдельно проверьте политику неактивности: иногда в профиле оболочки задан автоматический выход после простоя, и это выглядит как обрыв. Если сервер размещён у хостинга, уточните, нет ли у сети провайдера ограничений на долгие простаивающие соединения. Для важных задач, которые идут часами, запускайте их в мультиплексоре, чтобы обрыв не убивал работу.

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

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