Как создать сервис: Создание сервиса Linux. Как создать свой сервис для Linux с Systemd

пишем собственные .service и .target / Хабр

systemctl start apache2.service
systemctl start mysqld.service
/root/scripts/mysqld-tmpfs start

systemctl stop apache2.service
systemctl stop mysqld.service
/root/scripts/mysqld-tmpfs stop

Чего я хотел?

1. Мне было лень писать 2 команды (запуск apache и запуск mysql), т. к. я знал, что обе программы всегда будут выключаться и включаться синхронно. Хотелось выполнять эту операцию одной командой.
2. Дело попахивало неприятностями, если компьютер перезагрузится пока моя база данных будет сидеть в tmpfs – все файлы будут потеряны. Конечно, я делал бекапы, но мне опять же было лень восстанавливать их вручную после каждой непредвиденной перезагрузки.

Что я сделал?

Что такое service?

Что такое target?

systemctl isolate my-another.target

# Эксклюзивно включаем my-favorite.target и выключаем все остальные сервисы
systemctl isolate my-favorite.target
# К уже запущенным сервисам и targets добавляем еще 1 target
systemctl start my-another.target

Как я это сделал?

Description=Mount a MySQL database into tmpfs.
# Мой /root/scripts/tmpfs скрипт может работать как при включенном, так и при выключенном mysql сервисе. Но если бы mysql сервис нужен был включенным, к примеру, то я бы добавил эти строки:
#Requires=mysqld.service
#After=mysqld.service
[Service]
# Даем знать systemd, что этот сервис представляет из себя лишь 1 процесс. Man page хорошо описывает доступные опции.
  Type=oneshot
# Выполнить эту команду при запуске сервиса.
ExecStart=/root/scripts/mysqld-tmpfs start
# Выполнить эту команду при остановке сервиса.
ExecStop=/root/scripts/mysqld-tmpfs stop
# Даем знать systemd, что сервис нужно считать запущенным, даже если основной процесс прекратил свою работу. Как раз то, что мне нужно: мой процесс выполнит монтировку и после этого прекратит свою работу, но должен считаться активным, т.к. монтировка осталась в системе.
RemainAfterExit=yes

[Unit]
Description=Working/Programming target
Requires=mysqld.service
Requires=apache2.service
# Сюда я могу дописывать новые сервисы “Requires=another.service”, если они мне понадобятся в повседневной работе.

Какие были проблемы?

1. Запустится какой-то другой сервис, который в своей декларации указывает, что он конфликтует с нашим сервисом.
2. Выполнится systemctl isolate some-another.target или systemctl stop this.service.
3. Наш сервис может запросить в своей декларации останавливать себя не ленивым образом, а активным, добавив вот такую строку в [Unit] секцию: StopWhenUnneeded=true

Декларации “чужих” сервисов можно менять создавая файлы /etc/systemd/system/name-i-alter.service.d/*.conf. Я просто создал /etc/systemd/system/apache2.service/auto-stop.conf и /etc/systemd/system/mysqld.service.d/auto-stop.conf и поместил туда ту строку.

Другая проблема, на которую я, наткнулся была в том, что systemd не очень любит symlinks. Я не большой любитель “загаживать” системные директории типа /etc, /bin, /usr своими локальными продуктами жизнедеятельности, поэтому изначально я попытался свой /etc/systemd/system/mysqld-tmpfs.service сделать symlink на /root/scripts/mysqld-tmpfs.service файл, т.е. хранить сам файл в домашнем каталоге root пользователя. Но systemctl команда отказывалась работать с таким сервисом выдавая малопонятные ошибки. Оказалось, что определенную часть своей внутренней кухни systemd делает именно на symlinks, и ему тогда “трудно” отличать внутреннюю кухню (свои symlinks) от сторонних *.service файлов (если они тоже являются symlinks). Удалив symlink из /etc/systemd/system/mysqld-tmpfs.service и скопировав туда содержимое настоящего файла, я решил эту проблему. Более подробное описание этой проблемы можно прочитать тут: bugzilla.redhat.com/show_bug.cgi?id=955379

Результат

systemctl start programming.target

systemctl start mysqld-tmpfs.service

systemctl stop mysqld-tmpfs.service

systemctl stop programming. target

Cheat sheet

• Вызывайте systemctl daemon-reload, если вы изменили декларацию чего-либо (systemd считает файлы декларации заново)
• systemctl start my-name.(service|target) – запуск сервиса или target
• systemctl stop my-name.(service|target) – остановка сервиса или target
• systemctl enable my-name.service – сервисы могут декларировать при каких включенных targets они должны включаться. Для этого используется [Install] секция в файле декларации сервиса. Вы, как сисадмин, имеете власть на установку этого “пожелания” сервиса. Часто сервисы “устанавливаются” в target по умолчанию multi-user.target или в похожее.
• systemctl disable my-name.service – обратная операция по отношению к enable: деассоциировать связь между my-name.service и targets, которые он запросил в [Install] секции своей декларации.
• systemctl isolate my.target — включить все сервисы из my. target и выключить все остальные включенные сервисы.
• systemctl status my-name.(service|target) — узнать статус (запущен/остановлен) у сервиса или target.

Надеюсь, эта статья кому-то поможет при осваивании systemd. Я попытался сделать ее компактной, и если упустил из внимания какие-то дополнительные вопросы, спрашивайте в комментариях!

Systemd в Linux: пишем собственные юниты.

Systemd в Linux: пишем собственные юниты.

Mira Unix30 дек. 2016Руководства4 мин.

Пришло время рассказать о создании собственных юнитов systemd, тем более, что вы сами просили об этом в комментариях. Для примера я напишу сервис, который создает резервную копию директории перед выключением компьютера и подробно прокомментирую каждый этап. Но сначала — немного теории.

Если вы когда-либо играли в стратегии, то наверняка помните, что юнитами там называли единицу любой разновидности войск. Лучник, инженер, большой шагающий робот — все это юниты.

В контексте systemd юниты — это отдельные объекты, которыми управляет эта система. Как и игровые войска, они имеют свои разновидности, у каждой из которых  есть свое предназначение. Если вы читали предыдущие статьи, то знаете как минимум одну разновидность таких объектов — сервисы. Вот некоторые другие виды юнитов, о которых я, возможно, расскажу в следующих статьях:

• точки монтирования,
• таймеры,
• таргеты или цели,
• устройства.

Основными директориями для хранения юнитов в Ubuntu 16.04 являются:

• /lib/systemd/system — здесь находятся юниты, созданые автоматически при установке пакетов;
• /etc/systemd/system — пользовательские, вернее, администраторские юниты.

Скриншот выше демонстрирует содержимое директории с файлами юнитов.

Файлы юнитов содержат разделы с набором параметров и их значений, разделенных знаком «=». Слева название параметра, справа значение, все предельно просто. Для начала создадим файл с названием my_backup.service и поместим его в /etc/systemd/system. Впишем в него следующие строки:

[Unit]
Description = Backups my folder with projects
[Service]
RemainAfterExit=true
ExecStop=/usr/local/bin/my_backup
Type=oneshot
[Install]
WantedBy=multi-user.target

Идея этого решения принадлежит человеку с ником mezcalero из IRC чата systemd.

Давайте разберем представленный выше код.

Раздел [Unit] хранит общие сведения о юните. В данном случае он содержит только описание (Description).

Раздел [Service] объединяет сведения, необходимые для выполнения юнитом его задач. Type определяет тип сервиса (не путайте его с разновидностями юнитов), oneshot означает, что сервис должен выполнить разовую задачу и завершиться. ExecStop указывает скрипт, который должен быть выполнен перед остановкой сервиса. Есть еще ExecStart, этот параметр используется чаще и определяет команду, которая должна быть выполнена сразу после запуска сервиса. RemainAfterExit=true предписывает systemd считать процесс активным после его завершения.

Секция [Install] содержит сведения о том, при каких обстоятельствах должен быть запущен сервис. WantedBy=multi-user.target устанавливает запуск при обычной загрузке компьютера.

Но это еще не все. Скрипт, который мы указали в качестве значения ExecStop, на данный момент не существует.

#!/bin/bash
current_date="$(date +'%F_%H_%M')"
tar -czf /полный/путь/к/месту/хранения/резервной/копии/$current_date.tar.gz /полный/путь/к/папке/которую/нужно/архивировать

Приведенный выше код нужно поместить в файл /usr/local/bin/my_backup, а затем сделать его исполняемым:

sudo chmod +x /usr/local/bin/my_backup

Хотя наш скрипт совсем простой, давайте все же разберем его. Первая строка — обязательное начало любого bash скрипта. Вторая получает текущую дату и время в определенном нами формате и помещает ее в переменную current_date. Третья запускает архиватор и сообщает ему, что и куда архивировать. Кстати, не забудьте подставить свои пути вместо русского текста.

Теперь нам осталось лишь добавить наш сервис в автозагрузку и запустить его, чтобы он включился немедленно:

sudo systemctl enable my_backup  
sudo systemctl start my_backup

Обратите внимание: в команде выше я использовал mybackup, а не mybackup.service, хотя подразумевал именно это. Дело в том, что если тип юнита не указан, предполагается, что это .serivice. Полный вариант сработал бы точно так же.

Перезагрузите компьютер и проверьте, появился ли архив в указанном месте.

По желанию можно настроить сохранение резервных копий вне локального компьютера, например, в облачном хранилище. В этом случае может потребоваться проверка подключения к сети и доступности самого хранилища. Можно также настроить создание резервных копий не перед выключением, а по расписанию с помощью юнита timer. Возможно, в следующих статьях я продолжу эту тему и покажу, как это можно сделать, а заодно — продемонстрирую работу юнитов других типов.

Далеко не всегда нужно писать собственный скрипт при создании сервиса systemd. Зачастую сервисные файлы пишутся с целью управления уже существующими программами, путь к которым определяется параметрами ExecStart или ExecStop. Наш скрипт тоже использует существующую программу — tar. По большому счету, можно было обойтись и вовсе без него, сразу прописав все необходимые параметры в сервисном файле. Я включил его создание в статью только с целью демонстрации самой возможности. Но пользовательский скрипт все же будет полезен, если вы захотите усложнить задачу: отослать уведомление на электронную почту, удалить самый старый из архивов и т. д.

В скрипте я допустил ошибку, вследствие чего после перезагрузки компьютера резервной копии не обнаружилось. Установить причину было легко:

Вот так с помощью способа, описанного в прошлой статье, я легко нашел и устранил проблему. Вы тоже можете использовать этот способ, если что-то не заработает сразу. При следующей перезагрузке архив уже лежал в отведенном ему месте:

Если у вас возникли вопросы.

Приглашаю задавать их на сервисе вопросов и ответов: Ask.LinuxRussia.com.

Там ваши вопросы не потеряются и вы быстрее получите ответ, в отличие от комментариев.

Поделиться:

Статистика

Нравится Сайт? Подпишись!

 sc.exe create  binPath= ""
 

 sc create  binpath= ""
sc остановить 
sc queryex <имя_службы>
sc удалить 
 

 serman install 
 

 <услуга>
  привет
  <имя>привет
  Эта служба запускает приложение приветствия
  <исполняемый файл>node.exe
  
  "{{dir}}\hello.js"
  повернуть
  
  
  
  

 

 New-Service -Name "MyService" -BinaryPathName "C:\Path\to\myservice. exe"