Как проверить сокет-активацию до выкладки
Сокет-активацию удобно проверять до создания unit-файлов: отдельная команда открывает адрес и запускает вашу программу с переданным дескриптором. Так сразу видно, поддерживает она передачу сокета или нет.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Неизвестно, умеет ли программа принимать дескриптор
Это главный вопрос при переходе на сокет-активацию. Проверить его через unit-файлы долго и путано.
-
Нужно проверить несколько адресов сразу
Программы с несколькими сокетами требуют проверки каждого.
-
Нужен режим «по соединению»
Проверка простого обработчика, читающего со стандартного ввода, делается отдельным ключом.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Проверка передачи дескриптора без unit-файлов.
systemd-socket-activate -l 8080 /usr/local/bin/myappКто фактически держит порт во время проверки.
sudo ss -tlnp | grep 8080Решение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Это главный вопрос при переходе на сокет-активацию. Проверить его через unit-файлы долго и путано.
- Как проверить
-
Запустите программу через команду проверки.
systemd-socket-activate -l 8080 /usr/local/bin/myapp --systemd-socket 2>&1 | head
- Как исправить
- Если программа приняла дескриптор и отвечает на порту, активация заработает. Если открыла порт сама или упала, поддержки нет.
- Почему происходит
- Программы с несколькими сокетами требуют проверки каждого.
- Как проверить
-
Передайте несколько адресов.
systemd-socket-activate -l 8080 -l 8443 /usr/local/bin/myapp 2>&1 | head
- Как исправить
- Порядок дескрипторов соответствует порядку адресов. Если программа различает их по именам, задайте имена в описании сокета.
- Почему происходит
- Проверка простого обработчика, читающего со стандартного ввода, делается отдельным ключом.
- Как проверить
-
Запустите в режиме на каждое соединение.
systemd-socket-activate -l 7777 --inetd /usr/local/bin/handler 2>&1 | head
- Как исправить
-
Так проверяется схема с
Accept=yesдо создания шаблонной службы.
Пример вывода
Программа приняла переданный дескриптор. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
$ systemd-socket-activate -l 8080 /usr/local/bin/myapp
Listening on [::]:8080 as 3.
Communication attempt on fd 3.
Execing /usr/local/bin/myapp
myapp[4100]: using systemd socket fd=3Связанные ошибки
- Служба не получает сокет при сокет-активации Сокет активен, служба запускается, но не находит переданный дескриптор. Разбор: Accept, FileDescriptorName, соответствие имён.
- Сокет без Listen: unit загружен, но ничего не слушает В .socket не задан ни один параметр Listen…= — сокет не принимает соединения. Как объявить адрес прослушивания.
- Сокет отклоняет соединения: достигнут MaxConnections При Accept=yes число одновременных экземпляров ограничено. Как поднять предел и когда режим по соединению не подходит.
- Bad file descriptor в журнале службы Ошибка 9 при операции с файлом: дескриптор закрыт или не тот. Разбор для служб и сокет-активации.
- File exists при создании файла или сокета Ошибка 17: объект уже существует. Разбор для сокетов, файлов блокировки и каталогов службы.
- MySQL: Can't connect to local server through socket Клиент не находит unix-сокет MySQL: сервер не запущен, путь к сокету другой, каталог в /run не создан.
- Puma слушает сокет, а веб-сервер получает отказ доступа Разъём между приложением и веб-сервером: сокет создаётся с правами приложения, читает его другой пользователь.
- libvirtd: служба выключена, но виртуальные машины управляются Служба в состоянии inactive, а команды работают: включена активация по сокету. Как это устроено и что включать.
Источники
-
systemd-socket-activate(1)
Ключи команды и режимы проверки. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено на программе с поддержкой переданных сокетов и без неё.