Broken pipe ошибка debian
Обновлено: 07.07.2024
вопрос: есть ли способ, чтобы использовать flush=True на без BrokenPipeError ?
у меня есть скрипт pipe.py :
я называю это так из командной строки Unix:
и это возвращает:
так делает этот скрипт:
однако, когда я запускаю этот скрипт и вставьте его в head -n3000 :
тогда я получаю это ошибка:
Я также попробовал Решение ниже, но я все еще получаю BrokenPipeError :
на BrokenPipeError нормально, как сказал Фантом, потому что процесс чтения (head) завершается и закрывает свой конец трубы, пока процесс записи (python) все еще пытается писать.
Is и аномальное состояние, и скрипты python получают BrokenPipeError - точнее, интерпретатор Python получает системный сигнал SIGPIPE, который он ловит и поднимает BrokenPipeError чтобы скрипт мог обработать ошибку.
I слегка изменил свой скрипт на:
вот сценарий, который я использовал:
и вот результат python3.3 pipe.py | head -10 :
согласно документации Python, это выбрасывается, когда:
попытка написать на трубе, в то время как другой конец был закрыт
это связано с тем, что главная утилита читает из stdout , затем быстро закрывает его.
как вы можете видеть, это можно обойти, просто добавив sys.stdout.flush() после print() . Обратите внимание, что это иногда не работает в Python 3.
вы можете передайте это awk как это, чтобы получить тот же результат, что и head -3 :
надеюсь, это помогло, удачи!
как вы можете видеть на выходе, который вы опубликовали, последнее исключение возникает на этапе деструктора : вот почему у вас есть ignored В конце
простым примером, чтобы понять, что происходит в этом контексте, является следующее:
каждое исключение, которое запускается при уничтожении объекта, вызовет стандартную ошибку, объясняющую, что исключение произошло и проигнорировано (это потому, что python сообщит вам, что что-то не может быть правильно обрабатывать в фазе уничтожения). В любом случае, такого рода исключения не могут быть кэшированы, и поэтому вы можете просто удалить вызовы, которые могут его генерировать или закрыть stderr .
вернемся к вопросу. Это исключение не является реальной проблемой (как говорят, оно игнорируется), но если вы не хотите его печатать, вы должны переопределить функцию, которая может быть вызвана, когда объект будет уничтожен или закрыт stderr как @SergeBallesta правильно предложил : в вашем случае вы можете остановка write и flush функция и никакое исключение не будет вызвано в контексте уничтожения
Я знаю о screen , но это не тот ответ, который я ищу. Я думаю, что это вариант конфигурации sshd .
Возможно, ваш сервер закрывает слишком длинные простоя. Вы можете обновить либо ваш клиент ( ServerAliveInterval ), либо ваш сервер ( ClientAliveInterval )
Для обновления вашего сервера (и перезапустите sshd )
Или клиентская сторона:
Альтернативным решением было бы использовать mosh - мобильную оболочку . > . В отличие от ssh, он подключается через UDP и поддерживает роуминг. Вы можете начать свою сессию дома, приостановить работу своего ноутбука, взять его на работу /друзей /где бы вы ни располагали интернет, отказаться от своего ноутбука и продолжать работать так, как будто ничего не произошло. Это особенно полезно, если вы находитесь в паршивом интернет-соединении: он показывает мгновенную обратную связь, если ваши нажатия клавиш не доходят до сервера и постоянно пытается восстановить соединение.
Основная причина сбоев подключения заключается в том, что вам нужно добраться до сервера на UDP-порту (диапазон по умолчанию: 60000-61000) для работы mosh. Поэтому, если сервер находится за брандмауэром, вам в основном не повезло, если он не может пробить дыры в нем самостоятельно ( последствия для безопасности ).
Если вы хотите иметь более длительный период соединения, в клиенте добавьте:
ServerAliveCountMax по умолчанию это значение равно 3. Поэтому, когда ServerAliveInterval отправил 3 небольших пакета информации на ваш сервер, он автоматически выйдет из системы. Установка его на 1200 означает, что этот процесс должен произойти по крайней мере 1200 раз. Короче говоря, вы должны быть подключены не менее 30 * 1200 секунд (10 часов).
Обычно это означает, что ваше сетевое (TCP) соединение было сброшено. Например. ваш интернет-провайдер подключил вас или что-то вроде этого.
У меня была та же проблема, но это не так, как ожидалось. Если вы обнаружите, что в той же сети другой сервер пытается использовать тот же IP-адрес, вы столкнетесь с той же проблемой. Чтобы решить эту проблему, вам нужно проверить, есть ли другие серверы, которые используют один и тот же IP-адрес. Это можно сделать с помощью команды arp .
Я использую Debian, поэтому вот пример команд, которые я использую, чтобы определить, действительно ли другой сервер использует один и тот же IP-адрес.
Вы заметите два набора MAC-адреса, используя тот же IP-адрес. Избегайте конфликтов, установив один на другой IP-адрес.
Простой способ проверить, использует ли кто-нибудь другой IP-адрес:
- Отключите хост
- пинг одного и того же IP-адреса, чтобы узнать, использует ли другой компьютер этот IP-адрес
Чтобы узнать, какие компьютеры находятся в вашей сети, вы можете использовать этот Unix & Заголовок вопроса Linux: Как сделать найти, какие другие компьютеры подключены к локальной сети .
Главное меню » Linux » Исправление ошибки сломанной трубы с помощью SSH-соединения
Давайте посмотрим, что вызывает эту ошибку и как сохранить соединение SSH.
Исправление ошибки сломанной трубы с помощью SSH
Как вы уже догадались, соединение SSH закрыто из-за бездействия. Нет установленного значения, но обычно оно составляет около 5 минут или около того.
Таким образом, вы поддерживаете сеанс SSH в активном состоянии, потому что между клиентом и сервером существует связь, и сервер понимает, что клиент все еще существует.
- Если вы подключаетесь к нескольким серверам через SSH, установите его на своем компьютере.
- Если вы системный администратор и несколько пользователей жалуются на частое отключение SSH-соединения, вы можете установить его на сервере.
Метод 1: изменение конфигурации SSH на стороне клиента
Предположим, вы хотите, чтобы ваше SSH-соединение оставалось активным до 10 минут (600 секунд) простоя.
При подключении к удаленной системе Linux через SSH вы можете указать значение ServerAliveInterval:
Теперь это работает, но вручную вводить эту опцию каждый раз, когда вы подключаетесь к серверу, утомительно. Почему бы не сделать его постоянным?
Надеюсь, вы знаете о файлах конфигурации SSH. На стороне клиента вы можете воспользоваться этим, чтобы установить определенные параметры SSH для определенных подключений или всех из них.
Во-первых, убедитесь, что у вас есть файл конфигурации ssh. Если не создать:
Важно предоставить ему правильные права доступа к файлам, в противном случае при подключении через SSH у вас будет ошибка отказа в разрешении.
Используйте команду chmod и добавьте к ней следующие права доступа к файлу:
Если вам лень или вы не хотите вдаваться в подробности, используйте эту команду, чтобы установить интервал активности на 600 секунд (10 минут):
Это установит значение ServerAliveInterval на 10 минут для всех SSH-соединений, которые вы будете использовать. Попробуйте, если хотите.
Если вы хотите сделать его более правильным, вы должны добавить его так:
Метод 2: изменение конфигурации SSH на стороне сервера
Файл конфигурации SSH для сервера обычно находится в /etc/ssh/sshd_config.
Если вы откроете этот файл, вы найдете здесь два интересующих параметра:
Сохраните и выйдите из файла.
Пожалуйста, не устанавливайте тайм-аут SSH-соединения на несколько часов. Это было бы пустой тратой ресурсов.
Мы надеемся, что эта статья помогла вам решить проблему с ошибкой сломанной трубы при SSH-соединении. Ваше мнение приветствуется.
Вас тоже бесит постоянно отваливающееся соединение SSH? Меня это пипец как бесит. Особенно когда пишешь длинную команду, нажимаешь Enter, а тебе вываливается «client_loop: send disconnect: Broken pipe». И снова подключаешься.
Поиск по интернетам ничего не давал кроме того, что тут и там советовали раскомментировать директиву ClientAliveInterval, причем советовали установить значение в 300, причем не объясняя почему именно 300 и что вообще такое ClientAliveInterval.
Само собой я последовал совету и поставил ClientAliveInterval равным 300. Соединение как разрывалось до этого, так и дальше продолжало разрываться. А потом я где-то нашел совет добавить директиву ServerAliveInterval. В итоге сервер перестал отвечать и пришлось восстанавливать бэкап. Тем самым в трубу улетели кучи и кучи настроек, поскольку бэкап был один единственный и там была система в дефолтном состоянии.
За что отвечает директива ClientAliveInterval?
Значение этой директивы определяет через какой промежуток времени начиная с момента простоя клиенту будет отправлен запрос отклика. По умолчанию ClientAliveInterval равен 0, то есть сервер не будет ничего делать.
Простыми словами. У вас открыт терминал, вы подключены к серверу. Выполнили пару команд и ушли читать мануал. Допустим ClientAliveInterval у нас 30, это значи через 30 секунд после последней нашей активности, сервер проверит подключены ли мы к серверу, получив отклик от клиента, сервер не будет разрывать соединение.
Ну вроде как все понятно. Но! Чисто гипотетически мы можем быть подключены не через самое надежное соединение. Например через USB-модем в зоне со слабым сигналом. Предположим в какой-то момент сигнал упал, а сервер нам шлет запрос. Клиент его не получит. Тут на сцену выходит другая директива.
Директива ClientAliveCountMax
По умолчанию значение ClientAliveCountMax равно 3. То есть получается что сервер отправит нам максимум три запроса без подтверждения и уже только тогда закроет соединение.
Если ClientAliveInterval равен 30, а ClientAliveCountMax 3, то сервер закроет соединение через 90 секунд, то есть через полторы минуты, если наш модем за это время не восстановит соединение.
Как видите мы гибко можем манипулировать настройками этих двух директив в зависимости от обстоятельств.
Директива TCPKeepAlive
По умолчанию эта директива имеет значение yes. При активации ClientAliveInterval директиву TCPKeepAlive имеет смысл перевести в no. По сути сама по себе директива ничем особенным не помогает и не мешает, просто по мнению спецов, она может помочь злоумышленникам в атаке на сервер.
Добавляем настройки
У меня в Ubuntu Server 20.04 в файле /etc/ssh/sshd_config присутствует
Поэтому я просто создаю новый файл
И уже туда втыкаем
Я думаю этих настроек боле чем достаточно чтобы соединение долго не отваливалось в течении 15 минут. Это может показаться чрезмерным, но бывает всякое.
Читайте также: