Службы

Службы управляются системой инициализации systemctl.
Хорошая статья

Список активных служб

systemctl -a
systemctl -a | grep "myService"
systemctl list-units
list-init-files --type=service --state=enable
 
systemctl list-unit-files "my-name"

Enable/Disable не подразумевает Start/Stop с-но, даже после отключения службы (Disable), она продолжит работать, если уже была запущена.

Примеры

Описание директив

[Unit]
	Description=Kafka Service
	Requires=network.target remote-fs.target
	After=network.target remote-fs.target
 
[Service]
	Type=simple
	User=kafka
	ExecStart=/bin/sh -c '/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties > /opt/kafka/kafka.log 2>&1'
	ExecStop=ExecStop= /bin/kill -2 $MAINPID
	ExecReload=/bin/kill -HUP $MAINPID
	Restart=on-failure
 
[Install]
	WantedBy=multi-user.target

[Unit]
    Description=FProfilesAutoAcceleration service
    After=tank.mount
    After=network-online.target
 
[Service]
    ExecStart=java -Dcom.sun.management.jmxremote \
                   -Dcom.sun.management.jmxremote.port=10045 \
                   -Djava.rmi.server.hostname=10.10.40.204 \
                   -Dcom.sun.management.jmxremote.authenticate=false \
                   -Dcom.sun.management.jmxremote.ssl=false \
                   -jar FProfilesAutoAcceleration.jar \
                   -Xmx7G
    WorkingDirectory=/opt/FProfilesAutoAcceleration
    Restart=always
    TimeoutSec=15
    User=fprofilesac
 
[Install]
    Alias=fac.service

Инстансы Systemd

SystemD поддерживает функционал инстансов, удобно что к самому приложению особых требований не предъявляется, по сути используются повторные запуски с разными параметрами/окружениями

Суть в том что в юнит файле используем директиву «%i» везде где надо отразить уникальность инстанса, файл называем «myName@.service»
Далее, работаем с ним «systemctl start myName@one», «systemctl enable myName@two» и тд
Все что после собаки будет передаваться в юнит файл вместо директивы «%i», с-но гибкость очень высокая

Для сервиса спокойно можно создать два юнит-файла, дял единичного и для мульти (хотя хз надо ли)

Интересно что итогового юнит файла у зареганной службы нигде нет, есть только этот с собакой «myservice@.service»
При обращении к службе, переданное после собаки название просто подставляется в этот шаблон, так и работет похоже
Странно что после удаления пакета остается в зареганной службе, хоть и пишет что unit file not found

Пример мульти конфига

[Unit]
Description="myName for %i instance"
Requires=network-online.target consul.service
Wants=openvpn-server.service zfs.target
After=network-online.target openvpn-server.service zfs.target consul.service
 
[Service]
ExecStartPre=rm -f /opt/myName/log/%i.stdout
WorkingDirectory=/opt/myName
Environment=PYTHONUNBUFFERED=1
Type=exec
ExecStart=/usr/bin/python3 /opt/myName/myName.py -l critical -c %i_config.yaml -f log/%i.log
ExecStartPost=/bin/sleep 45
ExecStartPost=kill -0 $MAINPID
TimeoutStartSec=60
#Restart=on-failure
#RestartSec=5s
StandardOutput=file:/opt/myName/log/%i.stdout
 
[Install]
WantedBy=multi-user.target