Broken pipe ошибка что значит

В настоящее время Python считается зрелым языком программирования, который широко используется специалистами по обработке данных и инженерами по искусственному интеллекту (ИИ) из-за его простоты и легкочитаемого синтаксиса.

В данном руководстве мы обсудим [Errno 32] Broken pipe в Python, известное сообщение об ошибке, которое мы часто видим при взаимодействии с файловой системой. Мы разберем причину ее возникновения, а также способы ее избежать и исправить в коде.

«Сломанный канал» обычно считается ошибкой IOError (сокращение от «Ошибка ввода-вывода»), которая произошла на уровне системы Linux. Обычно она возникает при чтении и записи файлов или, другими словами, при выполнении ввода / вывода файлов или сетевого ввода / вывода (через сокеты).

Эквивалентная системная ошибка Linux – EPIPE, взятая из кодов ошибок GNU libc.

Макрос: int EPIPE

“Broken pipe.” означает, что на другом конце конвейера нет считывания процесса. Каждая функция библиотеки, вызывающая код ошибки, также выдает сигнал SIGPIPE; этот сигнал завершает программу, если не обрабатывается или не блокируется. Следовательно, программа никогда не отобразит EPIPE до тех пор, пока она не обработает или не заблокирует SIGPIPE.

Из приведенного выше утверждения мы можем сделать вывод, что система, отправляющая сигнал SIGPIPE, вызывает ошибку [Errno 32] Broken pipe в механизме межпроцессного взаимодействия Linux.

Например, система Linux внутренне использует другой сигнал, называемый SIGINT. В Linux команда Ctrl + C отправит сигнал SIGINT, чтобы завершить процесс, или мы можем использовать команду kill для достижения того же эффекта.

Python по умолчанию не игнорирует SIGPIPE. Однако он преобразует сигнал в исключение и вызывает ошибку – IOError: [Errno 32] Сломанный канал каждый раз, когда он получает SIGPIPE.

Ошибка “сломанный канал” при подключении к терминалу Linux

Всякий раз, когда мы сталкиваемся с ошибкой [Errno 32] Broken pipe при попытке передать вывод скрипта Python другой программе, например:

 
$ python file_name.py | head 

Объяснение:

Вышеупомянутый синтаксис конвейера создаст процесс, отправляющий данные в восходящем направлении, и процесс, читающий данные в нисходящем направлении. Когда нисходящему потоку не нужно читать данные восходящего потока, он отправит сигнал SIGPIPE процессу восходящего потока.

Когда нисходящий поток не должен читать данные восходящего потока? Давайте разберемся в этом на примере. Команда head в этом примере должна прочитать достаточно строк, чтобы сообщить восходящему потоку, что нам больше не нужно его читать, и она отправит сигнал SIGPIPE процессу восходящего потока.

Всякий раз, когда восходящий процесс является программой Python, возникает ошибка типа IOError: [Errno 32] Broken pipe.

Как избежать ошибки “сломанный канал”?

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

Синтаксис:

 
from signal import signal, SIGPIPE, SIG_DFL  
#Ignore SIG_PIPE and don't throw exceptions on it...(http://docs.python.org/library/signal.html) 
signal(SIGPIPE,SIG_DFL)  

Объяснение:

В приведенном выше фрагменте кода мы перенаправили сигналы SIGPIPE на стандартный SIG_DFL, который система обычно игнорирует.

Однако рекомендуется остерегаться руководства Python по библиотеке сигналов, чтобы предостеречь от такой обработки SIGPIPE.

Перехват IOError во избежание ошибки Broken pipe

Поскольку ошибка Broken pipe является ошибкой IOError, мы можем разместить блок try / catch, чтобы ее перехватить, как показано в следующем фрагменте кода:

Синтаксис:

 
import sys, errno 
try: 
    ### IO operation ### 
except IOError as e: 
    if e.errno == errno.EPIPE: 
        ### Handle the error ### 

Объяснение:

В приведенном выше фрагменте кода мы импортировали модуль sys и errno и разместили блок try / catch, чтобы перехватить возникшее исключение и обработать его.

Возможное решение проблемы в многопроцессорной программе

В программах, которые используют рабочие процессы для ускорения обработки и многоядерные процессоры, мы можем попытаться уменьшить количество рабочих процессов, чтобы проверить, сохраняется ли ошибка или нет.

Большое количество рабочих процессов может конфликтовать друг с другом при попытке взять под контроль ресурсы системы или разрешение на запись на диск.

Если вы используете SSH для подключения к удаленным серверам Linux, вы заметите, что если вы оставите сеанс SSH неактивным в течение некоторого времени, а затем попытаетесь использовать его снова, сеанс SSH отключается с сообщением об ошибке, например:

:client_loop: send disconnect: Broken pipe

В некоторых системах отображается сообщение: ‘Write failed: Broken pipe’ or ‘Connection closed by remote host’.

Давайте посмотрим, что вызывает эту ошибку и как сохранить соединение SSH.

Исправление ошибки сломанной трубы с помощью SSH

Как вы уже догадались, соединение SSH закрыто из-за бездействия. Нет установленного значения, но обычно оно составляет около 5 минут или около того.

Что вы можете сделать, чтобы избежать отключения сеанса SSH, — это отправить «живое сообщение» либо с сервера клиенту ( ClientAliveInterval), либо от клиента к серверу ( ServerAliveInterval) через определенный интервал времени.

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

Есть два способа сделать это. Либо вы отправляете живое сообщение от клиента к серверу, либо с сервера клиенту.

• Если вы подключаетесь к нескольким серверам через SSH, установите его на своем компьютере.
• Если вы системный администратор и несколько пользователей жалуются на частое отключение SSH-соединения, вы можете установить его на сервере.

Метод 1: изменение конфигурации SSH на стороне клиента

Предположим, вы хотите, чтобы ваше SSH-соединение оставалось активным до 10 минут (600 секунд) простоя.

При подключении к удаленной системе Linux через SSH вы можете указать значение ServerAliveInterval:

ssh -o ServerAliveInterval=600 username@server_ip_address

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

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

Во-первых, убедитесь, что у вас есть файл конфигурации ssh. Если не создать:

touch ~/.ssh/config

Важно предоставить ему правильные права доступа к файлам, в противном случае при подключении через SSH у вас будет ошибка отказа в разрешении.

Используйте команду chmod и добавьте к ней следующие права доступа к файлу:

chmod 600 ~/.ssh/config

Если вам лень или вы не хотите вдаваться в подробности, используйте эту команду, чтобы установить интервал активности на 600 секунд (10 минут):

echo "ServerAliveInterval 600" >> ~/.ssh/config

Это установит значение ServerAliveInterval на 10 минут для всех SSH-соединений, которые вы будете использовать. Попробуйте, если хотите.

Если вы хотите сделать его более правильным, вы должны добавить его так:

Host *
ServerAliveInterval 600

Метод 2: изменение конфигурации SSH на стороне сервера

Файл конфигурации SSH для сервера обычно находится в /etc/ssh/sshd_config.

Если вы откроете этот файл, вы найдете здесь два интересующих параметра:

• ClientAliveInterval: Это период времени бездействия, по истечении которого сервер отправит сообщение об активности подключенному по ssh клиенту.
• ClientAliveCountMax: Это количество попыток, которые сервер сделает для отправки живого сообщения.

Скажем, вы установили ClientAliveInterval в 200 секунд и ClientAliveCountMax в 3. Это означает, что сервер отправит живое сообщение через 200 секунд. Если со стороны клиента нет активности, он снова отправит живое сообщение через 400 секунд. Нет ответа/активности от клиента, и другое живое сообщение отправлено через 600 секунд. По истечении этого времени (600 секунд) соединение SSH прерывается.

Вы можете отредактировать файл /etc/ssh/sshd_config в своем любимом текстовом редакторе на базе терминала, таком как Vim. Найдите записи ClientAliveInterval и ClientAliveCountMax. Удалите ключ # в начале строк и присвойте им соответствующее значение.

Сохраните и выйдите из файла.

Пожалуйста, не устанавливайте тайм-аут SSH-соединения на несколько часов. Это было бы пустой тратой ресурсов.

Мы надеемся, что эта статья помогла вам решить проблему с ошибкой сломанной трубы при SSH-соединении. Ваше мнение приветствуется.

A pipe connects two processes. One of these processes holds the read-end of the pipe, and the other holds the write-end.

When the pipe is written to, data is stored in a buffer waiting for the other processes to retrieve it.

What happens if a process is writing to a pipe, but the process on the other side suddenly exits or closes the pipe? Or the other way round, a process is reading just as the writer finishes or closes?

This input/output error is called a broken pipe.