Broken pipe в журнале службы
Сообщение Broken pipe (номер 32, EPIPE) означает запись туда, где другая сторона уже закрылась. У сетевых служб это обычное дело — клиент отключился, — а у скриптов признак разорванного конвейера.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Клиент отключился, не дождавшись ответа
Для веб-серверов и API это нормальный ход событий: посетитель закрыл страницу. Тревожным становится только массовый характер таких записей.
-
Разорван конвейер в скрипте
Правая часть конвейера завершилась раньше, и левая получает ошибку записи. Классика при использовании команд, читающих только начало потока.
-
Приёмник вывода завершился
При выводе в сторонний обработчик его завершение оставляет службу с закрытым каналом.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Частота: единичные случаи и поток — разные ситуации.
journalctl -u myapp.service --since "1 hour ago" --no-pager | grep -ci "broken pipe"Куда идёт вывод и обрабатывается ли сигнал.
systemctl show myapp.service -p StandardOutput -p IgnoreSIGPIPEРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Для веб-серверов и API это нормальный ход событий: посетитель закрыл страницу. Тревожным становится только массовый характер таких записей.
- Как проверить
-
Посмотрите частоту сообщений.
journalctl -u myapp.service --since "1 hour ago" --no-pager | grep -c -i "broken pipe"
- Как исправить
- Единичные записи можно игнорировать. Массовые говорят о медленных ответах: клиенты не дожидаются.
- Почему происходит
- Правая часть конвейера завершилась раньше, и левая получает ошибку записи. Классика при использовании команд, читающих только начало потока.
- Как проверить
-
Посмотрите строку запуска и скрипт.
systemctl cat myapp.service | grep -E "^Exec"
- Как исправить
- Перепишите вызов без конвейера или обработайте разрыв в скрипте.
- Почему происходит
- При выводе в сторонний обработчик его завершение оставляет службу с закрытым каналом.
- Как проверить
-
Посмотрите настройки вывода.
systemctl show myapp.service -p StandardOutput -p StandardError
- Как исправить
- Переведите вывод в журнал: его приёмник всегда на месте.
Пример вывода
Клиенты отключаются, не дождавшись ответа. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
myapp[1200]: warn: write tcp <адрес>:8080-><адрес>:N: write: broken pipe
myapp[1200]: warn: client disconnected after 30.2sСвязанные ошибки
- signal=PIPE (status=13/PIPE) в systemd Процесс службы завершён сигналом PIPE: запись в закрытый канал или сокет. Частая причина — конвейер в ExecStart.
- Connection timed out в журнале службы Соединение не устанавливается по таймауту: пакеты отбрасываются, узел недоступен, перегружен сервер на другой стороне.
- nginx 502 Bad Gateway: connect() failed к приложению nginx работает, а приложение недоступно: connect() failed, connection refused, no such file or directory для сокета. Разбор 502.
- Address already in use при запуске службы Порт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
- Automount: каталог монтируется не вовремя или отваливается Автомонтирование через .automount: как работает TimeoutIdleSec, почему ресурс отваливается и когда лучше обычный .mount.
- Cannot assign requested address при привязке Ошибка 99 при привязке: адрес не принадлежит машине или ещё не поднят. Разбор с network-online.target и ip_nonlocal_bind.
- Connection refused в журнале службы Соединение отклонено: служба не может подключиться к базе, кешу или другому сервису. Порядок запуска, адрес, брандмауэр.
- Connection reset by peer в журнале службы Соединение сброшено другой стороной: обрыв клиента, перезапуск сервера, промежуточное устройство.
Где встречается чаще всего
Источники
- write(2): ошибка EPIPE
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено отключением клиента во время медленного ответа.