▶️ systemd socket activation: запуск сервиса только при реальном запросе
Обычно сервис в linux запускается заранее и постоянно висит в памяти:
systemctl start myapp
Даже если к нему никто не обращается, процесс уже работает, занимает ресурсы и ждет подключения. Но в systemd есть другой подход - socket activation. Идея простая:
• systemd заранее открывает socket или порт;
• сам сервис пока не запущен;
• приходит первый запрос;
• systemd стартует сервис;
• сервис получает уже открытое соединение или socket.
То есть приложение запускается не на всякий случай, а только когда к нему реально обратились. Классический пример - ssh.socket, cups.socket, docker.socket и разные локальные демоны.
Посмотреть активные сокеты:
systemctl list-sockets
Статус конкретного socket-unit:
systemctl status myapp.socket
▪️ Пример. Создаем /etc/systemd/system/myapp.socket:
[Unit]
Description=MyApp socket
[Socket]
ListenStream=8080
[Install]
WantedBy=sockets.target
И сервис /etc/systemd/system/myapp.service:
[Unit]
Description=MyApp service
[Service]
ExecStart=/usr/local/bin/myapp
Включаем именно сокет, а не service:
systemctl daemon-reload
systemctl enable --now myapp.socket
Теперь порт 8080 уже слушается, но сам myapp.service может быть не запущен. Проверяем:
ss -lntp | grep 8080
systemctl status myapp.service
Как только придет подключение на порт 8080, systemd запустит myapp.service.
▪️ Зачем это нужно:
• экономия ресурсов;
• ленивый запуск редко используемых сервисов;
• ускорение boot-процесса;
• возможность принимать соединения до старта приложения;
• меньше ручной логики вокруг кто должен стартовать первым;
• удобная модель для локальных демонов и admin-инструментов.
Особенно удобно, когда сервис нужен редко, но должен быть доступен сразу при обращении.
Socket activation работает не только с TCP-портами. Можно слушать Unix socket:
[Socket]
ListenStream=/run/myapp.sock
Это часто используют для локального взаимодействия между процессами.
#systemd #socketactivation
🧑💻 NetworkAdmin
Обычно сервис в linux запускается заранее и постоянно висит в памяти:
systemctl start myapp
Даже если к нему никто не обращается, процесс уже работает, занимает ресурсы и ждет подключения. Но в systemd есть другой подход - socket activation. Идея простая:
• systemd заранее открывает socket или порт;
• сам сервис пока не запущен;
• приходит первый запрос;
• systemd стартует сервис;
• сервис получает уже открытое соединение или socket.
То есть приложение запускается не на всякий случай, а только когда к нему реально обратились. Классический пример - ssh.socket, cups.socket, docker.socket и разные локальные демоны.
Посмотреть активные сокеты:
systemctl list-sockets
Статус конкретного socket-unit:
systemctl status myapp.socket
▪️ Пример. Создаем /etc/systemd/system/myapp.socket:
[Unit]
Description=MyApp socket
[Socket]
ListenStream=8080
[Install]
WantedBy=sockets.target
И сервис /etc/systemd/system/myapp.service:
[Unit]
Description=MyApp service
[Service]
ExecStart=/usr/local/bin/myapp
Включаем именно сокет, а не service:
systemctl daemon-reload
systemctl enable --now myapp.socket
Теперь порт 8080 уже слушается, но сам myapp.service может быть не запущен. Проверяем:
ss -lntp | grep 8080
systemctl status myapp.service
Как только придет подключение на порт 8080, systemd запустит myapp.service.
▪️ Зачем это нужно:
• экономия ресурсов;
• ленивый запуск редко используемых сервисов;
• ускорение boot-процесса;
• возможность принимать соединения до старта приложения;
• меньше ручной логики вокруг кто должен стартовать первым;
• удобная модель для локальных демонов и admin-инструментов.
Особенно удобно, когда сервис нужен редко, но должен быть доступен сразу при обращении.
Socket activation работает не только с TCP-портами. Можно слушать Unix socket:
[Socket]
ListenStream=/run/myapp.sock
Это часто используют для локального взаимодействия между процессами.
#systemd #socketactivation
🧑💻 NetworkAdmin