Systemd

Создание Сервиса в Systemd

Создайте service-файл (замените на имя вашего сервиса):

$ sudo touch /etc/systemd/system/foo-daemon.service
$ sudo chmod 664 /etc/systemd/system/foo-daemon.service

Откройте файл и пропишите минимальные настройки, которые позволят управлять сервисом с помощью :

Description=Foo


ExecStart=/usr/sbin/foo-daemon


WantedBy=multi-user.target

Путь К Демону: Если вы не знаете путь к демону, попробуйте .

После создания нового service-файла необходимо перезапустить systemd:

$ sudo systemctl daemon-reload

Теперь вы можете делать , , и проверять сервиса:

$ sudo systemctl start foo-daemon
$ sudo systemctl stop foo-daemon
$ sudo systemctl restart foo-daemon
$ systemctl status foo-daemon

Чтобы добавить сервис в автозагрузку, необходимо активировать его:

$ sudo systemctl enable foo-daemon

Чтобы проверить логи сервиса, выполните:

$ journalctl -u foo-daemon

Примечания

1. ↑
2. Lennart Poettering, , 0pointer. Проверено 16 июня 2011.
3. Lennart Poettering (2012-04-21), . Проверено 28 апреля 2012.
4. Sievers, Kay, . Проверено 25 мая 2012.
5. Lennart Poettering (2010-04-30), . Проверено 14 декабря 2011.
6. Jake Edge (2011-07-27), . Проверено 14 декабря 2011.
7. . www.hippolab.ru. Дата обращения 9 ноября 2015.
8. Lennart Poettering (2011-05-18), , GNOME. Проверено 26 мая 2011.
9. Dj Walker-Morgan (2011-05-24), , The H. Проверено 26 мая 2011.
10. Dj Walker-Morgan (2011-08-29), , The H. Проверено 29 августа 2011.
11. , Archlinux Wiki. Проверено 9 марта 2011.
12. , 2012-10-13
13. , 2012-10-13
14. , 2012-11-04
15. , Debian wiki. Проверено 21 июля 2011.
16. , Gentoo Packages

Systemd Service File Examples

Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target


Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true


WantedBy=multi-user.target

Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target


Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true


WantedBy=multi-user.target

Description=Redis persistent key-value database
After=network.target


ExecStart=/usr/bin/redis-server /etc/redis.conf --daemonize no
ExecStop=/usr/bin/redis-shutdown
User=redis
Group=redis


WantedBy=multi-user.target

For more examples, check the systemd.service and systemd.unit man pages.

Conclusion

By now, you should be familiar with some of the basic capabilities of the command that allow you to interact with and control your instance. The utility will be your main point of interaction for service and system state management.

While operates mainly with the core process, there are other components to the ecosystem that are controlled by other utilities. Other capabilities, like log management and user sessions are handled by separate daemons and management utilities (/ and / respectively). Taking time to become familiar with these other tools and daemons will make management an easier task.

Writing user units

See for general information about writing systemd unit files.

Example

The following is an example of a user version of the mpd service.

~/.config/systemd/user/mpd.service

Description=Music Player Daemon


ExecStart=/usr/bin/mpd --no-daemon


WantedBy=default.target

Example with variables

The following is an example of a user version of , which takes into account variable home directories where SickBeard can find certain files:

~/.config/systemd/user/sickbeard.service

Description=SickBeard Daemon


ExecStart=/usr/bin/env python2 /opt/sickbeard/SickBeard.py --config %h/.sickbeard/config.ini --datadir %h/.sickbeard


WantedBy=default.target

As detailed in , the variable is replaced by the home directory of the user running the service. There are other variables that can be taken into account in the systemd manpages.

Reading the journal

The journal for the user can be read using the analogous command:

$ journalctl --user

To specify a unit, one can use

$ journalctl --user-unit myunit.service

Or, equivalently:

$ journalctl --user -u myunit.service

Systemd: управление автозагрузкой служб в Linux

В большистве популярных современных популярных дистрибутивов Linux (CentOS 7, RHEL, Debian, Fedora и Ubuntu) в качестве демона автозагрузки вместо init.d используется systemd. Systemd – менеджер системы и служб Linux, используется для запуска других демонов и управления ими в процессе работы, использует unit-файлы из /etc/systemd/system (init.d использовал скрипты из каталога /etc/init.d/). Systemd позволяет распараллелить запуск служб в процессе загрузки ОС, тем самым ускоряя запуск.

Для управления system используется команда systemctl.

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

Список unit-файлов можно получить командой:

Данная команда отобразит все доступные юнит-файлы (не зависимо от того, были они загружены в systemd после загрузки ОС или нет).

Чтобы вывести список активных сервисов и их состояние, выполните:

Следующая команда выведет список юнитов, которые загрузил или пытался загрузить systemd. Так как после запуска некоторые юниты могут стать неактивными, с помощью флага —all вы получите полный список.

UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active waiting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
● exim.service not-found inactive dead exim.service
firewalld.service loaded active running firewalld - dynamic firewall daemon
getty@tty1.service loaded active running Getty on tty1
● ip6tables.service not-found inactive dead ip6tables.service
● ipset.service not-found inactive dead ipset.service
● iptables.service not-found inactive dead iptables.service
Bring up/down networking
● NetworkManager-wait-online.service not-found inactive dead

Как видим из списка, здесь отображаются даже сервисы, которые не были найдены на диске «not-found».

Использую данную команду, вы можете добавить и другие флаги, например:

• —state — используется для определения состояния демона Load, Active, Sub
• —type — позволяет фильтровать юниты по их типу.

Примеры:

— выведет список только активных юнитов

— выведет список юнитов, которые являются сервисом.

Добавление сервиса в systemd

Для управления сервисами в systemd используется особый синтаксис. После имени серверсв в конце нужно указывать .service. Например:

– команда добавит в автозагрузку веб-сервер nginx

Данная команда создаст символическую ссылку на копию файла, указанного в команде сервиса, в директории автозапуска systemd.

Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service

Вывод этой команды показывает в какой директории был создан симлинк на файл сервиса.

Чтобы посмотреть добавлен тот или иной сервис в автозагрузку, можно проверить его статус:

При выводе нужно обратить внимание на строку:

Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)

Значение enabled означает что данный сервис загружается автоматически (добавлен в автозагрузку). Если сервис не загружается автоматом, здесь буде указано disabled.

Удаление сервиса из systemd

Вы можете удалить сервис из автозагрузки, чтобы он не запускался после старта Linux (при этом сам сервис с сервера не удаляется). Чтобы удалить сервис из автозагрузки, выполните команду:

Например, чтобы удалить из автозагрузки nginx, выполните:

Removed symlink /etc/systemd/system/multi-user.target.wants/nginx.service

После выполнения команды, симлинк на файл сервиса будет удален из директории systemd. Можно проверить, есть ли юнит в автозагрузке:

Systemd: маскировка юнитов

В моей практике встречались «вредные» сервисы, которые после удаления их из автозагрузки, все равно там оставались и запускались после рестарта ОС. Чтобы решить этот вопрос, можно замаскировать сервис:

И после этого, он вообще не будет запускаться, ни вручную, ни после перезагрузки ОС:

Created symlink from /etc/systemd/system/nginx.service to /dev/null.

Redirecting to /bin/systemctl restart nginx.service
Failed to restart nginx.service: Unit is masked.

Снять маску можно командой:

Removed symlink /etc/systemd/system/nginx.service.

Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked):

Таким нехитрым способом, можно избавить себя от удаления сервиса, даже если он не удаляется из автозагрузки systemd.

Timer units

Timers are systemd unit files with a suffix of . Timers are like other and are loaded from the same paths but include a section which defines when and how the timer activates. Timers are defined as one of two types:

• Realtime timers (a.k.a. wallclock timers) activate on a calendar event, the same way that cronjobs do. The option is used to define them.
• Monotonic timers activate after a time span relative to a varying starting point. They stop if the computer is temporarily suspended or shut down. There are number of different monotonic timers but all have the form: . Common monotonic timers include and .

For a full explanation of timer options, see the . The argument syntax for calendar events and time spans is defined in .

Note: systemd offers the target which sets up all timers that should be active after boot (see for details). To use it, add to the section of your timer and enable the timer unit.

Create Systemd Service File

Create a systemd service file (replace the with your service name):

$ sudo touch /etc/systemd/system/foo-daemon.service
$ sudo chmod 664 /etc/systemd/system/foo-daemon.service

Open the file and add the minimal service configuration options that allow this service to be controlled via :

Description=Foo


ExecStart=/usr/sbin/foo-daemon


WantedBy=multi-user.target

Path To Daemon: If you don’t know the full path to a daemon, try .

Once the service file is changed, it needs to reload systemd configuration:

$ sudo systemctl daemon-reload

Now you should be able to , , and check the service

$ sudo systemctl start foo-daemon
$ sudo systemctl stop foo-daemon
$ sudo systemctl restart foo-daemon
$ systemctl status foo-daemon

To configure a service to start automatically on boot, you need to it:

$ sudo systemctl enable foo-daemon

To check the service logs, run:

$ journalctl -u foo-daemon

relayd: по трем фронтам

Какая связь между мониторингом сетевых хостов, балансировкой нагрузки и прокси-сервером? Все это функции одной машины? Да, вполне возможно. Но что если я скажу, что все эти три функции тесно связаны между собой и должны быть реализованы в рамках одного универсального приложения? Бред? Никак нет.

Возьмем, к примеру, достаточно распространенную в узких кругах функцию сервера под названием «распределение нагрузки между несколькими DNS-серверами». Что нужно для ее решения? Во-первых, умение перенаправлять DNS-трафик на другой хост (от балансировщика к одному из реальных DNS-серверов).

Это можно сделать с помощью брандмауэра или особым образом настроенного BIND (несколько тяжеловесный вариант). Вовторых, умение выбирать наиболее подходящего кандидата для обработки запроса из списка DNS-серверов. Это уже сложнее, и здесь может понадобиться специализированное ПО или опять же брандмауэр (но очень хороший). В-третьих, умение проверять DNS-сервера на доступность и удалять упавших из списка. Нужен скрипт, пингующий хосты и управляющий списками, либо особые возможности брандмауэра (а такой есть?). В общем, долгое нудное велосипедостроение или покупка специализированного решения для конкретной задачи по нереальным ценам. А что если завтра вдруг понадобится сделать нечто подобное для SMTP?

Все править или вновь открывать кошелек? Не стоит, содержимое кошелька все-таки лучше приберечь, а костыли с велосипедами оставить спортсменам. Демон relayd, появившийся в OpenBSD 4.3, позволяет решить эту и еще огромное количество других, подобных и не очень, задач всего за несколько минут.

Он включает в себя возможности балансировщика нагрузки для протоколов уровней 3, 4 и 7, прокси уровня 7 (релей) и сервиса проверки доступности сетевых узлов (из которого и вырос).

На основе relayd можно строить самые разные конфигурации, начиная от простых прокси-серверов или SSL-акселераторов и заканчивая сложными решениями вроде прозрачных web-прокси с фильтрацией запросов и распределением нагрузки между несколькими web-серверами. И все это с помощью простого конфигурационного файла, длина которого даже в самых сложных конфигурациях редко превышает 50 строк.

Да, конечно, без примера все это только слова. Так что вот рабочий конфиг, полностью удовлетворяющий требованиям, выдвинутым в начале раздела:

Переменные и макросы

table <dns_servers> { 192.168.1.1, 192.168.1.2, 192.168.1.3 }

Общие настройки

log updates

Настройки DNS-протокола

dns protocol «dnsfi lter» { tcp { nodelay, sack, socket buffer 1024, backlog 1000 } }

Настройки релея

relay dnsproxy {

DNS-серверов, предварительно проверив его на доступность

forward to <dns_servers> port 53
mode loadbalance check tcp
}

Наиболее важные части этого конфига находятся в теле директив dns protocol и relay. Первая представляет собой нечто вроде шаблона, который используется для того, чтобы не повторять одни и те же настройки протоколов в других частях конфигурационного файла (relayd поддерживает три протокола: HTTP, DNS и TCP). Вторая — это настройка релея, в котором указаны прослушиваемый порт, проксируемый протокол, его настройки и информация о том, каким образом и какому хосту должны быть перенаправлены пакеты. В нашем случае прокси должен отправить DNS-запрос одному из трех серверов с предварительной проверкой на доступность (здесь используется проверка методом TCP-рукопожатия, но relayd поддерживает множество других методов, начиная от ping и заканчивая попыткой установить SSLсоединение). При этом, если один из DNS-серверов окажется в дауне, relayd автоматически исключит его из списка до тех пор, пока плановая проверка на доступность (интервал между проверками указан в опции interval) не покажет его работоспособность.

Для тестирования конфигурации можно использовать следующую форму запуска relayd:

Так демон не уйдет в фон и будет вести подробную распечатку всех своих действий. После отладки конфигурации можно настроить запуск демона во время загрузки системы. Для этого достаточно поместить строку relayd_flags=»» в файл /etc/rc.conf.local.

Возможности

Помимо простого запуска и контроля служб, systemd предлагает некоторые другие удобные функции, для использования которых ранее системным администраторам приходилось прибегать к помощи дополнительных программ-демонов. Среди таких функций:

• сокет-активация служб (заменяет inetd);
• запуск сервисов по расписанию (заменяет cron);
• работа с аппаратным сторожевым таймером (заменяет watchdog);
• смена корня (заменяет chroot);
• автомонтирование томов и сетевых ресурсов (заменяет mount и fstab);
• journalctl — служба журналирования;
• systemd-analyze — анализ скорости запуска служб;
• systemd-boot — UEFI загрузчик(замена grub).

Приложение состоит из нескольких компонент

Вообразите следующее: веб-сайт. Скорее всего у вас будет база данных, например mysql, веб-сервер, например nginx, интерпретатор php скриптов, например hhvm, а  еще в довесок самописная служба, выполняющая бэкап по расписанию, например backup.sh.

При обычном раскладе, чтобы всё это загрузить вы даете команды

А можно создать unit, назвать его mysite.target и использовать всего одну команду

С таргетами можно делать всё то же самое, что и с обычными юнитами, например их можно перезапускать:

Как же правильно составить файл systemd target? Давайте рассмотрим создание таргета на приведенном примере:

Не забываем перечитывать конфигурацию:

Готово! Вот так простым описанием зависимостей мы сгруппировали юниты. Запуская mysite.target, systemd увидит, что для своего запуска он требует такие и такие юниты, и запустит их. Помните, что директива «Requires=» жестко устанавливает зависимости и, если хотя бы один из юнитов по каким-то причинам не сможет запуститься, запуск таргета также не состоится. Если вам это не подходит, используйте вместо «Requires=» «Wants=». «Wants=» мягко устанавливает зависимость и не падает, если какой-то из компонент не сможет запуститься. Директивы «After=» и «Before=» зависимость не устанавливают, но устанавливают последовательность запуска. Один таргет может зависеть от другого таргета и т.д.

systemd components

Some (not exhaustive) components of systemd are:

• systemd-boot — simple UEFI boot manager;
• systemd-firstboot — basic system setting initialization before first boot;
• systemd-homed — portable human-user accounts;
• systemd-networkd — network configuration management;
• systemd-nspawn — light-weight namespace container;
• systemd-resolved — network name resolution;
• — creates system users and groups and adds users to groups at package installation or boot time;
• systemd-timesyncd — system time synchronization across the network;
• systemd/Journal — system logging;
• systemd/Timers — monotonic or realtime timers for controling files or events, reasonable alternative to cron.

systemd.mount — mounting

systemd is in charge of mounting the partitions and filesystems specified in . The translates all the entries in into systemd units, this is performed at boot time and whenever the configuration of the system manager is reloaded.

systemd extends the usual fstab capabilities and offers additional mount options. These affect the dependencies of the mount unit, they can for example ensure that a mount is performed only once the network is up or only once another partition is mounted. The full list of specific systemd mount options, typically prefixed with , is detailed in .

An example of these mount options in the context of automounting, which means mounting only when the resource is required rather than automatically at boot time, is provided in .

GPT partition automounting

For and automounting to work, the PARTUUID must match the SHA256 HMAC hash of the partition type UUID keyed by the machine ID. The required PARTUUID can be obtained using:

$ systemd-id128 -u --app-specific=partition-type-UUID machine-id

Note: reads the machine ID from , this makes it impossible to know the needed PARTUUID before the system is installed.

The automounting of a partition can be disabled by changing the partition’s or setting the partition attribute bit 63 «do not automount», see .

systemd-sysvcompat

(required by ) primary role is to provide the traditional linux init binary. For systemd controlled systems, is just a symbolic link to its executable.

In addition, it also provides 4 convenience short cuts that SysVinit users might be used to. The convenience short cuts are , , and . Each one of those 4 commands is a symbolic link to , and governed by systemd behavior. Therefore, the discussion at applies.

systemd-tmpfiles — temporary files

«systemd-tmpfiles creates, deletes and cleans up volatile and temporary files and directories.» It reads configuration files in and to discover which actions to perform. Configuration files in the former directory take precedence over those in the latter directory.

Configuration files are usually provided together with service files, and they are named in the style of . For example, the Samba daemon expects the directory to exist and to have the correct permissions. Therefore, the package ships with this configuration:

/usr/lib/tmpfiles.d/samba.conf

D /run/samba 0755 root root

Configuration files may also be used to write values into certain files on boot. For example, if you used to disable wakeup from USB devices with , you may use the following tmpfile instead:

/etc/tmpfiles.d/disable-usb-wake.conf

#    Path                  Mode UID  GID  Age Argument
w    /proc/acpi/wakeup     -    -    -    -   USBE

See the and man pages for details.

Note: This method may not work to set options in since the systemd-tmpfiles-setup service may run before the appropriate device modules is loaded. In this case you could check whether the module has a parameter for the option you want to set with and set this option with a . Otherwise you will have to write a to set the appropriate attribute as soon as the device appears.

Temporary files

«systemd-tmpfiles creates, deletes and cleans up volatile and temporary files and directories.» It reads configuration files in and to discover which actions to perform. Configuration files in the former directory take precedence over those in the latter directory.

Configuration files are usually provided together with service files, and they are named in the style of . For example, the Samba daemon expects the directory to exist and to have the correct permissions. Therefore, the package ships with this configuration:

/usr/lib/tmpfiles.d/samba.conf

D /run/samba 0755 root root

Configuration files may also be used to write values into certain files on boot. For example, if you used to disable wakeup from USB devices with , you may use the following tmpfile instead:

/etc/tmpfiles.d/disable-usb-wake.conf

w /proc/acpi/wakeup - - - - USBE

See the and man pages for details.

Note: This method may not work to set options in since the systemd-tmpfiles-setup service may run before the appropriate device modules is loaded. In this case you could check whether the module has a parameter for the option you want to set with and set this option with a . Otherwise you will have to write a to set the appropriate attribute as soon as the device appears.