В настоящее время 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, чтобы перехватить возникшее исключение и обработать его.
Возможное решение проблемы в многопроцессорной программе
В программах, которые используют рабочие процессы для ускорения обработки и многоядерные процессоры, мы можем попытаться уменьшить количество рабочих процессов, чтобы проверить, сохраняется ли ошибка или нет.
Большое количество рабочих процессов может конфликтовать друг с другом при попытке взять под контроль ресурсы системы или разрешение на запись на диск.
Изучаю Python вместе с вами, читаю, собираю и записываю информацию опытных программистов.
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.
Sometimes my SSH session disconnects with a Write failed: Broken pipe message. What does it mean? And how can I keep my session open?
I know about screen, but that’s not the answer I’m looking for. I think this is a sshd config option.
asked Sep 14, 2010 at 9:04
Peter StuifzandPeter Stuifzand
1,9712 gold badges12 silver badges7 bronze badges
It’s possible that your server closes connections that are idle for too long.
You can update either your client (ServerAliveInterval) or your server (ClientAliveInterval)
ServerAliveInterval
Sets a timeout interval in seconds after which if no data has
been received from the server, ssh(1) will send a message through
the encrypted channel to request a response from the server. The
default is 0, indicating that these messages will not be sent to
the server. This option applies to protocol version 2 only.
ClientAliveInterval
Sets a timeout interval in seconds after which if no data has
been received from the client, sshd(8) will send a message
through the encrypted channel to request a response from the
client. The default is 0, indicating that these messages will
not be sent to the client. This option applies to protocol
version 2 only.
To update your server (and restart your sshd)
echo "ClientAliveInterval 60" | sudo tee -a /etc/ssh/sshd_config
Or client-side:
echo "ServerAliveInterval 60" >> ~/.ssh/config
answered Sep 14, 2010 at 9:56
5
If you want to have a longer connection period, in the client add:
echo 'ServerAliveInterval 30' | tee -a ~/.ssh/config
echo 'ServerAliveCountMax 1200' | tee -a ~/.ssh/config
ServerAliveCountMax by default this is set to 3. Therefore once the ServerAliveInterval has sent 3 small packs of info to your server it will then automatically log out. Setting it to 1200 means this process will have to occur at least 1200 times. In short you should be connected at least 30*1200 seconds (10 hours).
answered Jul 4, 2015 at 22:40
5
An alternative solution would be to use mosh — the mobile shell. In contrast to ssh it connects via UDP and supports roaming. You can start your session at home, suspend your laptop, take it to work / friends / wherever else you have internet, unsuspend your laptop and continue to work as if nothing has happened. It is especially useful if you are on a lousy internet connection: It shows instant feedback if your keystrokes don’t reach the server and continuously tries to reestablish the connection.
Installation and setup are simple: It is now included in all current Linux (plus a few non-Linux) distributions and it coordinates the session initialization and authentication via a prior ssh connection. So if you are able to connect via ssh user@server you are very likely to be able to connect with mosh just by calling mosh user@server, if the mosh packages are installed on both ends.
The main reason for connection failures is that you have to reach the server on a UDP port (default range: 60000-61000) for mosh to work. So if the server is behind a firewall you are mostly out of luck if can’t punch holes in it yourself (security implications).
answered Aug 11, 2014 at 8:26
PerseidsPerseids
4635 silver badges11 bronze badges
I spent lots of time messing with ServerAliveInterval and ClientAliveInterval variables with no joy.
Finally, after comparing with a machine that did not have the broken pipe problem, I found the directive at the bottom of /etc/ssh/sshd_config:
KeepAlive yes
Putting this at the bottom of my problem server’s /etc/ssh/sshd_config did the trick.
Verified for Ubuntu 20.04.1 LTS, Ubuntu 16.04.7 LTS.
answered Jan 6, 2021 at 23:38
NormanNorman
611 silver badge1 bronze badge
3
It usually means that your network (TCP) connection was reset. E.g. your internet provider reconnected you or something like this.
answered Sep 14, 2010 at 9:44
maxschlepzigmaxschlepzig
55.7k48 gold badges202 silver badges276 bronze badges
0
I had the same problem but it is not as expected. If you find that on the same network another server is trying for the same IP address, you will face the same problem.
To solve this you need to check if there are other servers which use your same IP address. This can be done using the arp command.
I am using Debian so here is a sample of the commands that I use to determine if another server was indeed using the same IP address
apt-get install arp-scan
arp-scan -I eth0 -l | grep 192.168.1.42
192.168.1.42 d4:eb:9a:f2:11:a1 (Unknown)
192.168.1.42 f4:23:a4:38:b5:76 (Unknown) (DUP: 2)
You will notice two sets of mac address using the same IP address. Avoid conflict by setting one to another IP address.
steve
21.5k5 gold badges48 silver badges75 bronze badges
answered Dec 29, 2015 at 8:56
Another cause for the «Broken Pipe message» is that another machine is attempting use the same IP as your host.
A simple way to test if someone else is using that IP:
- Turn off your host
- ping the same IP to see if another machine is using that IP
To find out which machines are on your network, you can use this Unix & Linux question title: How to find what other machines are connected to the local network.
answered Apr 26, 2013 at 21:06
JosirJosir
1303 bronze badges
1
You can use SSH/SCP argument ‘-o‘ to accomplish that, no need to set your (if you’re admin) server’s ssh-config.
SSH options related to keeping connection alive are
TCPKeepAlive,ServerAliveCountMax,ServerAliveInterval.
Basically, it goes like this:
% ssh -o TCPKeepAlive=yes
-o ServerAliveCountMax=20
-o ServerAliveInterval=15
user@server.example
, to have the client sending «keep-alive» messages every 15 seconds until the limit of 20 messages — which amounts to 20 x 15 seconds = 5 minutes —, at which point the connection is considered broken/dead. The client process ends.
The man pages will give you more, detailed information:
- https://linux.die.net/man/5/ssh_config
answered Jul 23, 2020 at 8:56
BrandtBrandt
2821 gold badge2 silver badges10 bronze badges
For me this was because I had used ChrootDirectory which requires that the entire path given be owned by root (which it was not for me). Changing the permissions for the path and restarting sshd fixed the problem.
answered Feb 2, 2021 at 11:58
QwertieQwertie
1,1943 gold badges13 silver badges28 bronze badges
2
You must log in to answer this question.
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.
Если вы используете 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-соединении. Ваше мнение приветствуется.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
BrokenPipeError at /ru/api/v1/my_url/
[Errno 32] Broken pipe
Request Method: POST
Request URL: https://apihrc.wienerdeming.com/ru/api/v1/my_url/
Django Version: 2.0
Python Executable: /my_project/.venv/bin/uwsgi
Python Version: 3.6.1
Python Path: [‘.’, », ‘/my_project/.venv/lib64/python36.zip’, ‘/my_project/.venv/lib64/python3.6’, ‘/my_project/.venv/lib64/python3.6/lib-dynload’, ‘/usr/lib64/python3.6’, ‘/usr/lib/python3.6’, ‘/my_project/.venv/lib/python3.6/site-packages’, ‘/my_project’, ‘/my_project/apps’]
Server time: Пн, 30 Июл 2018 16:02:43 +0500
Installed Applications:
[‘django.contrib.admin’,
‘django.contrib.auth’,
‘django.contrib.contenttypes’,
‘django.contrib.sessions’,
‘django.contrib.messages’,
‘django.contrib.staticfiles’,
‘django.contrib.gis’,
‘easy_thumbnails’,
‘django_filters’,
‘rest_framework’,
‘dynamic_rest’,
‘rest_framework.authtoken’,
‘easy_pdf’,
‘corsheaders’,
‘parler’,
*’my_apps’
]
Installed Middleware:
[‘raven.contrib.django.middleware.SentryMiddleware’,
‘django.middleware.security.SecurityMiddleware’,
‘django.contrib.sessions.middleware.SessionMiddleware’,
‘django.middleware.locale.LocaleMiddleware’,
‘corsheaders.middleware.CorsMiddleware’,
‘django.middleware.common.CommonMiddleware’,
‘django.middleware.csrf.CsrfViewMiddleware’,
‘django.contrib.auth.middleware.AuthenticationMiddleware’,
‘django.contrib.messages.middleware.MessageMiddleware’,
‘django.middleware.clickjacking.XFrameOptionsMiddleware’,
‘system.utils.middleware.RequestLogsMiddleware’]
Traceback:
File «/my_project/.venv/lib/python3.6/site-packages/django/core/handlers/exception.py» in inner
35. response = get_response(request)
File «/my_project/.venv/lib/python3.6/site-packages/django/core/handlers/base.py» in _get_response
128. response = self.process_exception_by_middleware(e, request)
File «/my_project/.venv/lib/python3.6/site-packages/django/core/handlers/base.py» in _get_response
126. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File «/my_project/.venv/lib/python3.6/site-packages/django/views/decorators/csrf.py» in wrapped_view
54. return view_func(*args, **kwargs)
File «/my_project/.venv/lib/python3.6/site-packages/rest_framework/viewsets.py» in view
95. return self.dispatch(request, *args, **kwargs)
File «/my_project/.venv/lib/python3.6/site-packages/rest_framework/views.py» in dispatch
494. response = self.handle_exception(exc)
File «/my_project/.venv/lib/python3.6/site-packages/rest_framework/views.py» in handle_exception
454. self.raise_uncaught_exception(exc)
File «/my_project/.venv/lib/python3.6/site-packages/rest_framework/views.py» in dispatch
491. response = handler(request, *args, **kwargs)
File «/my_project/.venv/lib/python3.6/site-packages/rest_framework/mixins.py» in create
21. self.perform_create(serializer)
File «/my_project/.venv/lib/python3.6/site-packages/rest_framework/mixins.py» in perform_create
26. serializer.save()
File «/my_project/.venv/lib/python3.6/site-packages/rest_framework/serializers.py» in save
214. self.instance = self.create(validated_data)
File «/usr/lib64/python3.6/contextlib.py» in inner
53. return func(*args, **kwds)
File «/my_project/apps/applications/serializers/application_action.py» in create
83. self._submit_to_client(application, validated_data.get(‘comment’, «»))
File «/my_project/apps/applications/serializers/application_action.py» in _submit_to_client
113. send = gmail.messages.send_message(message=message)
File «/my_project/apps/mailboxes/utils/gmail/messages.py» in send_message
129. message = self.service.users().messages().send(userId=’me’, body=message).execute()
File «/my_project/.venv/lib/python3.6/site-packages/googleapiclient/_helpers.py» in positional_wrapper
130. return wrapped(*args, **kwargs)
File «/my_project/.venv/lib/python3.6/site-packages/googleapiclient/http.py» in execute
835. method=str(self.method), body=self.body, headers=self.headers)
File «/my_project/.venv/lib/python3.6/site-packages/googleapiclient/http.py» in _retry_request
179. raise exception
File «/my_project/.venv/lib/python3.6/site-packages/googleapiclient/http.py» in _retry_request
162. resp, content = http.request(uri, method, *args, **kwargs)
File «/my_project/.venv/lib/python3.6/site-packages/oauth2client/transport.py» in new_request
175. redirections, connection_type)
File «/my_project/.venv/lib/python3.6/site-packages/oauth2client/transport.py» in request
282. connection_type=connection_type)
File «/my_project/.venv/lib/python3.6/site-packages/httplib2/__init__.py» in request
1322. (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File «/my_project/.venv/lib/python3.6/site-packages/httplib2/__init__.py» in _request
1072. (response, content) = self._conn_request(conn, request_uri, method, body, headers)
File «/my_project/.venv/lib/python3.6/site-packages/httplib2/__init__.py» in _conn_request
996. conn.request(method, request_uri, body, headers)
File «/usr/lib64/python3.6/http/client.py» in request
1239. self._send_request(method, url, body, headers, encode_chunked)
File «/usr/lib64/python3.6/http/client.py» in _send_request
1285. self.endheaders(body, encode_chunked=encode_chunked)
File «/usr/lib64/python3.6/http/client.py» in endheaders
1234. self._send_output(message_body, encode_chunked=encode_chunked)
File «/usr/lib64/python3.6/http/client.py» in _send_output
1065. self.send(chunk)
File «/usr/lib64/python3.6/http/client.py» in send
986. self.sock.sendall(data)
File «/usr/lib64/python3.6/ssl.py» in sendall
965. v = self.send(data[count:])
File «/usr/lib64/python3.6/ssl.py» in send
935. return self._sslobj.write(data)
File «/usr/lib64/python3.6/ssl.py» in write
636. return self._sslobj.write(data)
Exception Type: BrokenPipeError at /ru/api/v1/my_url/
Exception Value: [Errno 32] Broken pipe
Request information:
USER: admin2