Broken pipe linux что это

How to fix Broken Pipe Error in Linux

Have you ever encountered a situation in which you were unable to download any package on your Linux machine ? Or you might have probably seen an error like package not installed? This kind of error can easily be fixed with a command like “sudo apt install –f”. On rare occasions, you may have experienced a broken pipe error.

A pipe in Linux / Unix connects two processes , one of them has read-end of the file and the other one has the write-end of the file. When a process writes to a Pipe, it gets stored in a buffer and gets retrieved by the other process. Broken pipe occurs when a process prematurely exits from either end and the other process has not yet closed the pipe.

Example use case:

A user has just recently reinstalled RVM (Ruby Version Manager) after he performed a fresh install of Ubuntu.

He then opened up the terminal and issued the command:

type rvm | head -1

This issued the following error:

rvm is a function -bash: type: write error: Broken pipe

What happened here is that when the user runs the command type rvm | head -1 , bash has actually executed type rvm in one process and head -1 in another process. The stdout of the type part is connected to the “write” end of a pipe whereas the stdin of the head part is hooked up to the “read” end. Note that the two processes have run concurrently ( at the same time ).

The head -1 process has carried out a read operation of data from stdin , then prints out a single line (as dictated by the -1 option) before exiting, causing therefore the “read” end of the pipe to be closed. Since the rvm function has quite a long data stream (about 11 kB after having been bash parsed and reconstructed), which means that head exits yet at the same time type still has some data to write out (few KB).

Since type is trying to carry out a write operation to a pipe whose other end has therefore been closed – a brokenpipe routine or the write() function that it invoked, will return an EPIPE error which is known as “Broken pipe”.

Inspecting the Command

In most cases, this might not be the case but the first step you should check is whether the command issued was right or not. You should reissue the command and check whether it gets executed or not. You can also try issuing commands like “sudo apt update” and “sudo apt install –f” as these commands are not destructive in nature. If your problem still persists, try rebooting the machine and see whether the problem was resolved or not.

Fixing a Problem with File System

When you have issued the commands mentioned earlier multiple times and you still get the error, check whether the error reads something like “read-only file system” in the terminal output. This may be caused when your boot partition gets mounted as read-only for some reason. The problem could be caused by some faulty software installation when the system decides that it is not safe to write to the drive.

The other cause might be when you try to install something from apt and the installer needs to access some resource in read mode, but cannot perform the read operation properly. It may throw an error like “sudo: cannot mount”. This error occurs because most of the ‘entities’ in Linux are files and in order to read a resource, Linux would need to open that file and read it. If however another process is currently using that resource, then it may not be possible to read the file. Also, when the reading process exits abruptly and does not close the file, it may corrupt the file until the next boot.

If you still cannot access the files even after rebooting, then the problem could be bigger than anticipated. You may have a broken file system. To resolve this issue, you may need a stable Linux environment in order to work on the broken system. The best way to do this is to boot from a Live Linux USB drive and work from it.

This is the right moment to backup all your data. Although the following steps are safe, you should make sure to store your data on a secure device.

Once you boot into a Live USB drive you should start to check for the partitions with a corrupt file system. To do so, issue the following command:

sudo fsck.ext4 -fv /dev/sdaX”

Note that here X stands for the partition that you are trying to scan. Note that this command is for partitions of type ext4. If you have a partition of type ext3 or ext2 you will need to replace the command with “fsck.ext3” and “fsck.ext2” respectively. This will scan your drive and print the output on the terminal (note the -v flag). Alternatively, you can specify a -c flag to surface-scan the drive; it will look for bad sectors on the drive.

Once you have done this, your partition should hopefully been fixed. Now Boot into your machine and issue the command:

sudo mount -o rw,remount /

This will restore the read/write permission on your drive and will therefore solve the broken pipe issue.

Afterwords

You have just seen one solution to resolve the broken pipe issue, but a broken pipe is not a problem, it could be a symptom of a larger problem more often than not. You can have a broken pipe whenever you are trying to read a stream like resource that gets closed prematurely. .

If you like the content, we would appreciate your support by buying us a coffee. Thank you so much for your visit and support.

Источник

Что означает сообщение Broken pipe в сеансе SSH?

Иногда мой сеанс SSH отключается с сообщением Write failed: Broken pipe . Что это значит? И как я могу открыть сеанс?

Я знаю о screen , но это не тот ответ, который я ищу. Я думаю, что это вариант конфигурации sshd .

6 ответов

Возможно, ваш сервер закрывает слишком длинные простоя. Вы можете обновить либо ваш клиент ( ServerAliveInterval ), либо ваш сервер ( ClientAliveInterval )

Для обновления вашего сервера (и перезапустите sshd )

Или клиентская сторона:

Альтернативным решением было бы использовать mosh — мобильную оболочку . > . В отличие от ssh, он подключается через UDP и поддерживает роуминг. Вы можете начать свою сессию дома, приостановить работу своего ноутбука, взять его на работу /друзей /где бы вы ни располагали интернет, отказаться от своего ноутбука и продолжать работать так, как будто ничего не произошло. Это особенно полезно, если вы находитесь в паршивом интернет-соединении: он показывает мгновенную обратную связь, если ваши нажатия клавиш не доходят до сервера и постоянно пытается восстановить соединение.

Установка и настройка просты: теперь он включен во все текущие дистрибутивы Linux (плюс несколько не Linux) и координирует инициализацию и аутентификацию сеанса через предыдущее соединение ssh. Поэтому, если вы можете подключиться через ssh [email protected] , вы, скорее всего, сможете подключиться к mosh, просто позвонив mosh [email protected] , если пакеты mosh установленный на обоих концах.

Основная причина сбоев подключения заключается в том, что вам нужно добраться до сервера на UDP-порту (диапазон по умолчанию: 60000-61000) для работы mosh. Поэтому, если сервер находится за брандмауэром, вам в основном не повезло, если он не может пробить дыры в нем самостоятельно ( последствия для безопасности ).

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

ServerAliveCountMax по умолчанию это значение равно 3. Поэтому, когда ServerAliveInterval отправил 3 небольших пакета информации на ваш сервер, он автоматически выйдет из системы. Установка его на 1200 означает, что этот процесс должен произойти по крайней мере 1200 раз. Короче говоря, вы должны быть подключены не менее 30 * 1200 секунд (10 часов).

Обычно это означает, что ваше сетевое (TCP) соединение было сброшено. Например. ваш интернет-провайдер подключил вас или что-то вроде этого.

У меня была та же проблема, но это не так, как ожидалось. Если вы обнаружите, что в той же сети другой сервер пытается использовать тот же IP-адрес, вы столкнетесь с той же проблемой. Чтобы решить эту проблему, вам нужно проверить, есть ли другие серверы, которые используют один и тот же IP-адрес. Это можно сделать с помощью команды arp .

Я использую Debian, поэтому вот пример команд, которые я использую, чтобы определить, действительно ли другой сервер использует один и тот же IP-адрес.

Вы заметите два набора MAC-адреса, используя тот же IP-адрес. Избегайте конфликтов, установив один на другой IP-адрес.

Другая причина для сообщения «Broken Pipe» заключается в том, что другой компьютер пытается использовать тот же IP-адрес, что и ваш хост.

Простой способ проверить, использует ли кто-нибудь другой IP-адрес:

1. Отключите хост
2. пинг одного и того же IP-адреса, чтобы узнать, использует ли другой компьютер этот IP-адрес

Чтобы узнать, какие компьютеры находятся в вашей сети, вы можете использовать этот Unix & Заголовок вопроса Linux: Как сделать найти, какие другие компьютеры подключены к локальной сети .

Источник

Ошибка «client_loop: send disconnect: Broken pipe»

Вас тоже бесит постоянно отваливающееся соединение 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 минут. Это может показаться чрезмерным, но бывает всякое.

Источник

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

Главное меню » Linux » Исправление ошибки сломанной трубы с помощью SSH-соединения

В некоторых системах отображается сообщение: ‘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. На стороне клиента вы можете воспользоваться этим, чтобы установить определенные параметры SSH для определенных подключений или всех из них.

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

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

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

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

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

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

Метод 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-соединении. Ваше мнение приветствуется.

Источник