Сокет отключён: сработало ограничение частоты активаций
Если служба, вызываемая сокетом, падает сразу после запуска, соединения продолжают её вызывать, и получается цикл. systemd защищается ограничением частоты активаций и отключает сокет целиком.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Служба падает при запуске
Каждое новое соединение вызывает её снова. Цикл упирается в ограничение частоты за секунды.
-
Ограничение слишком строгое для нагрузки
При режиме по соединению каждое подключение — это активация. На нагруженной службе значение по умолчанию может срабатывать без всякой поломки.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Сообщение об ограничении частоты активаций.
journalctl -u myapp.socket -n 30 --no-pagerДействующие пределы и режим работы сокета.
systemctl show myapp.socket -p TriggerLimitIntervalSec -p TriggerLimitBurst -p AcceptРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Каждое новое соединение вызывает её снова. Цикл упирается в ограничение частоты за секунды.
- Как проверить
-
Посмотрите состояние службы и её журнал.
systemctl status myapp.service --no-pager | head -10 journalctl -u myapp.service -n 30 --no-pager
- Как исправить
-
Исправьте причину падения службы, затем перезапустите сокет. Ограничение частоты тут лишь защита, а не проблема.
sudo systemctl restart myapp.socket
- Почему происходит
- При режиме по соединению каждое подключение — это активация. На нагруженной службе значение по умолчанию может срабатывать без всякой поломки.
- Как проверить
-
Посмотрите значения ограничения.
systemctl show myapp.socket -p TriggerLimitIntervalSec -p TriggerLimitBurst
- Как исправить
-
Поднимите предел активаций или перейдите на
Accept=no, чтобы служба обслуживала соединения сама.
Пример вывода
Сокет отключён из-за цикла активаций. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
systemd[1]: myapp.socket: Trigger limit hit, refusing further activation.
systemd[1]: myapp.socket: Failed with result 'trigger-limit-hit'.
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILUREСвязанные ошибки
- start-limit-hit: служба заблокирована после серии перезапусков Состояние start-limit-hit и сообщение start request repeated too quickly: systemd перестал перезапускать службу. Как разблокировать и найти исходную причину.
- Служба не получает сокет при сокет-активации Сокет активен, служба запускается, но не находит переданный дескриптор. Разбор: Accept, FileDescriptorName, соответствие имён.
- status=1/FAILURE в systemd Код 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
- Bad file descriptor в журнале службы Ошибка 9 при операции с файлом: дескриптор закрыт или не тот. Разбор для служб и сокет-активации.
- File exists при создании файла или сокета Ошибка 17: объект уже существует. Разбор для сокетов, файлов блокировки и каталогов службы.
- MySQL: Can't connect to local server through socket Клиент не находит unix-сокет MySQL: сервер не запущен, путь к сокету другой, каталог в /run не создан.
- Puma слушает сокет, а веб-сервер получает отказ доступа Разъём между приложением и веб-сервером: сокет создаётся с правами приложения, читает его другой пользователь.
- libvirtd: служба выключена, но виртуальные машины управляются Служба в состоянии inactive, а команды работают: включена активация по сокету. Как это устроено и что включать.
Источники
-
systemd.socket(5)
TriggerLimitIntervalSec= и TriggerLimitBurst=. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено связкой сокета и падающей службы.