Systemd для продолжающих. Part 2 — Триггеры на различные события

Продолжаем цикл популярного балета, под названием «Systemd для продолжающих». В этой части, являющейся логическим продолжением предыдущей, поговорим о различных триггерах не связанных со временем. Эта часть будет не такой объёмной, но, не менее интересной. Вперёд!

Systemd.path — триггер на события в файловой системе

Как известно, linux имеет большое количество системных вызовов, среди которых имеется замечательный вызов inotify() , позволяющий вешать обработчики на события в файловой системе — на создание, удаление, изменение etc, файлов и каталогов. Наиболее распространёнными утилитами, использующими inotify() являются утилиты inotifywait и inotifywatch из пакета inotify-tools, которые хорошо использовать в скриптах, а так же проект incron — cron для файловой системы, о котором уже писали на Хабре. Systemd тоже имеет специальные юниты, которые хоть и ограничены по функционалу (я надеюсь пока), по сравнению с incron и тем более с inotify-tools , но зато умеют запускать юниты systemd.

Практическое применение systemd.path

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

$ cat /etc/systemd/system/enable-radeon.path
[Unit]
Description=Enable radeon path

[Path]
PathExists=/sys/kernel/debug/vgaswitcheroo/switch

[Install]
WantedBy=multi-user.target

Всё то же самое, как и в случае с таймерами. Если в основной секции, в данном случае [Path], не указана директива Unit=, ищем и запускаем одноимённый *.service:

$ cat /etc/systemd/system/enable-radeon.service
[Unit]
Description=Enable radeon service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/sh -c "echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch"

[Install]
WantedBy=multi-user.target

Итак всё просто. Энейблим *.path — sudo systemctl enable enable-radeon.path и, во время загрузки, как только в дереве файловой системы появляется файл (PathExists=) /sys/kernel/debug/vgaswitcheroo/switch, запускаем соответствующий сервис.

Возможные директивы слежения для systemd.path

К сожалению их мало, но базовые потребности для старта каких-либо юнитов они, в принципе, покрывают:

• PathExists= Триггерится на появление файла или директории, в файловой системе.

• PathExistsGlob= То же самое что и предыдущая директива, но можно использовать файлы / каталоги по маске.

• PathChanged= Если в файле или каталоге произошли изменения, при этом он не будет реагировать на каждый вызов write(), а сработает только после первого close()

• PathModified= Подобно предыдущему, только в этом случае не ждём close(), а сразу реагируем на первый попавшийся write().

• DirectoryNotEmpty= Как понятно из названия — срабатывает только в отношении директорий, когда в директории появляется хотя-бы один файл.

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

Дополнительные параметры

• Unit= Юнит для запуска. Важное замечание, о котором я забыл в предыдущей статье. В параметре Unit= не обязательно может быть *.service, но и любой другой (кроме *.path) юнит. Например *.mount.

• MakeDirectory= Булевый параметр. Создавать-ли каталоги слежения. По умолчанию — false.

• DirectoryMode= Связанный с предыдущим параметром параметр раздачи прав на создаваемую директорию. По умолчанию 0755.

Сравнение функционала systemd.path c incron и inotify-tools

В таблице пропущено парочка специфичных для incron параметров.

И да, чуть не забыл. Все утилиты использующие inotify() работают только и исключительно на локальных файловых системах. То-есть, например, на SMB / NFS они работать не будут, но при этом спокойно будут работать в /run, /sys, /proc!

Systemd.automount — триггеры автомонтирования ФС

Очень простые юниты позволяющие как сэкономить немного времени, при загрузке системы, так и немного обезопасить критические (не все, с корнем такой трюк не пройдёт) файловые системы, от повреждения в случае, например, пропадания питания.

Практика

Сразу два примера. Для автомонтирования локальной и удалённой файловой системы. Два *.automount и два *.mount юнита к ним в пару. В отличие от *.timer и *.path юнитов в случае автомаунта отсутствует директива Unit=, поэтому используется или одноимённый «persistent» *.mount, что предпочтительнее, либо *.mount автоматически сгенерированный из содержимого /etc/fstab.

Первый пример: Локальная файловая система, смонтированная в /boot. По большому счёту, содержимое каталога /boot практически не нужно при работе системы. Исключение — обновление ядра и соответственно обновление initrd образов и конфигурации загрузчика, что бывает, не сказать что-бы часто. Поэтому, мы спокойно можем выслать раздел /boot в автомонтирование.

$ cat /etc/systemd/system/boot.automount
[Unit]
Description=Automount boot partition when needed.

[Automount]
Where=/boot
## Time to automatic umount of inactivity
TimeoutIdleSec=120

[Install]
WantedBy=multi-user.target

И в пару к нему одноимённый *.mount файл:

$ cat /etc/systemd/system/boot.mount
[Unit]
Description=Boot partition (running by automount) /dev/sda1
Documentation=man:systemd.mount(5)
After=blockdev@dev-disk-by\x2duuid-ea65285a\x2d01da\x2d451c\x2da93a\x2d4b155c46aeeb.target

[Mount]
Where=/boot
What=/dev/disk/by-uuid/ea65285a-01da-451c-a93a-4b155c46aeeb
Type=ext4
Options=rw,relatime
DirectoryMode=0755

Всё практически как в fstab, только раскидано по нескольким строчкам. Что происходит в автомаунте: Когда какой-либо процесс пытается прочитать/записать что-то в каталоге /boot или получить его листинг, автомаунт запускает одноимённый юнит *.mount и начинает мониторить обращения к /boot. Через 2 минуты после последнего обращения (TimeoutIdleSec=), раздел будет автоматически отмонтирован.

И второй пример, который я всё никак не соберусь перевести на rclone — автомонтирование облака яндекса, когда я к нему обращаюсь.

$ cat /etc/systemd/system/home-oxyd-Clouds-yadisk.automount
[Unit]
Description=Automount yandex disc when needed.

[Automount]
Where=/home/oxyd/Clouds/yadisk
DirectoryMode=0777
## Time to automatic umount of inactivity
TimeoutIdleSec=300

[Install]
WantedBy=multi-user.target

И «ответочка» к нему:

$ cat /etc/systemd/system/home-oxyd-Clouds-yadisk.mount
[Unit]
Description=Yandex disk automounted drive
Documentation=man:systemd.mount(8) 

[Mount]
Where=/home/oxyd/Clouds/yadisk
What=https://webdav.yandex.ru/
Type=davfs
Options=noauto,user

Тут тоже всё прозрачно, единственно добавлен параметр раздачи прав для создания директории, если таковой не окажется на законном месте. Да у автомаунта ровно три параметра:

• Where= Путь который мониторим.

• TimeoutIdleSec= Таймаут перед автоотмонтированием, если параметр отсутствует, или равен 0 (по умолчанию) раздел не автоотмонтируется.

• DirectoryMode= права на создание каталога для мониторинга, по умолчанию 0755.

Вот, вкратце, как-то примерно так. И, как всегда, какие маны почитать:

man systemd.path
man 7 inotify
man inotifywait
man inotifywatch
man systemd.automount
man systemd.mount
man systemd-mount
man 5 fstab
man systemd.time

Список статей серии

1. Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0

2. Systemd для продолжающих. Part 1 — Запуск юнитов по временным событиям

3. Systemd для продолжающих. Part 2 — Триггеры на различные события

Ресурсы

• systemd.io — Статьи по внутренней кухне systemd. Частенько упоминается в манах.

• systemd @ freedesktop.org — Основная страница с манами, документацией, видео, блогами и прочими ссылками на ресурсы.

• @ru_systemd — Русскоязычный чат в Telegram. У нас тепло и лампово.