Порт занят, но процесса не видно
Если порт занят, а владельца найти не удаётся, почти всегда дело в сетевом пространстве имён: процесс работает в контейнере или в изолированной службе, и обычный просмотр соединений его не видит.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Порт держит контейнер
Проброс порта контейнера выглядит в системе как процесс среды исполнения, а не как ваша служба. Иногда владельцем оказывается процесс пробрасывания портов.
-
Порт держит сокет systemd
При сокет-активации адрес открыт менеджером. В выводе виден процесс systemd, и это сбивает с толку.
-
Процесс в другом сетевом пространстве имён
Служба с
PrivateNetwork=yesили процесс в пространстве имён контейнера не виден обычными средствами хоста.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Владелец порта: без прав root имя процесса не показывается.
sudo ss -tlnp | grep :ПОРТСетевые пространства имён на машине.
sudo lsns -t netАдреса, которые держит сам systemd.
systemctl list-sockets --no-pagerРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Проброс порта контейнера выглядит в системе как процесс среды исполнения, а не как ваша служба. Иногда владельцем оказывается процесс пробрасывания портов.
- Как проверить
-
Посмотрите владельца порта и контейнеры.
sudo ss -tlnp | grep :8080 docker ps --format "{{.Names}} {{.Ports}}" 2>/dev/null | head
- Как исправить
- Освободите порт в описании контейнера или выберите другой для службы.
- Почему происходит
- При сокет-активации адрес открыт менеджером. В выводе виден процесс systemd, и это сбивает с толку.
- Как проверить
-
Посмотрите активные сокеты.
systemctl list-sockets --no-pager | grep 8080
- Как исправить
- Остановите сокет или откажитесь от самостоятельной привязки в службе.
- Почему происходит
- Служба с
PrivateNetwork=yesили процесс в пространстве имён контейнера не виден обычными средствами хоста.
- Как проверить
-
Посмотрите пространства имён и соединения в них.
sudo lsns -t net | head sudo ss -tlnp -N $(pgrep -o myapp) 2>/dev/null | head
- Как исправить
- Смотрите соединения внутри нужного пространства имён. Для служб проверьте параметры сетевой изоляции.
Пример вывода
Порт держит процесс пробрасывания портов контейнера. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
$ sudo ss -tlnp | grep :8080
LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:(("docker-proxy",pid=2100,fd=4))
myapp[4400]: fatal: listen tcp :8080: bind: address already in useСвязанные ошибки
- Address already in use при запуске службы Порт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
- Служба не получает сокет при сокет-активации Сокет активен, служба запускается, но не находит переданный дескриптор. Разбор: Accept, FileDescriptorName, соответствие имён.
- status=225/NETWORK в systemd Код 225/NETWORK: не удалось создать сетевое пространство имён для службы при PrivateNetwork=yes или NetworkNamespacePath=.
- PostgreSQL: could not bind IPv4 address Кластер PostgreSQL не занимает порт: адрес занят другим экземпляром или остался файл сокета. Разбор.
- bind: Permission denied при привязке к порту Отказ при привязке к порту: обычно порт ниже 1024 у службы от непривилегированного пользователя. Как дать возможность CAP_NET_BIND_SERVICE.
- dnsmasq: failed to create listening socket for port 53 Порт 53 занят встроенной службой разрешения имён. Как развести dnsmasq и systemd-resolved.
- Apache: could not bind to address Apache не занимает порт: конфликт с nginx, порт занят, нет прав на привилегированный порт.
- Automount: каталог монтируется не вовремя или отваливается Автомонтирование через .automount: как работает TimeoutIdleSec, почему ресурс отваливается и когда лучше обычный .mount.
Где встречается чаще всего
Источники
-
ss(8)
Просмотр соединений и ключи для пространств имён. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено пробросом порта контейнера на тот же порт, что у службы.