LINUX.ORG.RU
решено ФорумAdmin

Нестандартные условия в systemd unit

 ,


1

2

Есть некая самописная приблуда. Большая и страшная. Стартует сразу после того, как запустилась сеть и подрубились сетевые диски. С них тянет часть данных, в них ковыряется, разбирает, берёт входные данные и только потом начинает работать.

При останове аналогично. Сперва лезет на диски, смотрит, проверяет, считает, пишет и только потом останавливается.

Я в упор не могу понять, как сделать юнит с зависимостями от сетевых дисков(они у меня монтируются после поднятия сети в /etc/network/interfaces с помощью post-up по sshfs) и потом только поднимать эту самую приблуду.

Ладно с ним, с ресурсами, там же ещё действия нужно перед запуском произвести. Посчитать, посмотреть и только потом стартовать.

В общем, где подробно почитать, как в этом systemd писать развёрнутые условия и как при старте системы использовать произвольные параметры?

Тут не нужны особые условия, вполне штатная последовательность:

Приблуда зависит от сетевых дисков, сетевые диски зависят от сети (After=network.target). Нужно написать два новых сервис файла для приблуды и sshfs. За основу можно взять готовые сервис файлы в /usr/lib/systemd/system. Новые сервис-файлы нужно сохранить в /etc/systemd/system

В общем, где подробно почитать

man systemd.service

disarmer ★★★
()
Ответ на: комментарий от shell-script

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

disarmer ★★★
()
Ответ на: комментарий от disarmer

А ведь раньше было просто и достаточно прописать всё что нужно и в нужной последовательности в /etc/rc.conf.

Теперь же без пол-литры не разберёшься, что от кого зависит и когда стартует.

Прогресс!

Прям, как в том анекдоте из unixhaters: «Конечно, она портит ваши файлы, но зато как быстро!» ;)

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 3)

ИМХО проще всего из юнита вызывать скрипт, который и делает проверки и т.д

at ★★
()
Ответ на: комментарий от disarmer

А в чём тогда смысл systemd? Я-то пытаюсь понять, как там всё задумано, раз уж оно в дебиане по-дефолту. А выходит, что стало только сложнее. Раньше был просто скрипт, который можно почитать, поправить и отдебажить, а теперь есть чёрный ящик, которому в любом случае скармливаешь скрипт, но уже хз, как с ним разбираться.

shell-script ★★★★★
() автор топика
Ответ на: комментарий от beastie

Не, ты не нагнетай. Я честно пытаюсь разобраться.

Хотя пока я с тобой согласен. :)

shell-script ★★★★★
() автор топика
Ответ на: комментарий от shell-script

Раньше был просто скрипт

Тот скрипт не распараллелишь, хитрые зависимости надо в голове считать, автоматически сервис не добавишь(надо лезть в скрипт, искать место, вписывать нужное). Теперь все сервисы, где не требуется сложной логики описываются декларативно в ~10 строк.

чёрный ящик

А раньше было N черных ящиков - систем инициализации, с которыми тоже надо было разбираться. Теперь хотя бы унификация

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

Второй вариант - добавить монтирование сетевых дисков с проверками отдельным сервисом - но особого преимущества над скриптом нет, пока от него один сервис зависит

disarmer ★★★
()
Ответ на: комментарий от beastie

прописать всё что нужно

Всё что нужно и его зависимости. А потом ждать пока это всё прогрузится по очереди, пока все остальные ядра процессора простаивают

что от кого зависит и когда стартует.

systemd-analyze dot lxdm.service|dot -Tsvg > systemd.svg

Пример: http://disarmer.ru/upload/data/1/systemd.svg

Видимо у других инитов были проблемы, раз ментейнеры выбрали systemd. Причём ментейнеры почти всех дистрибутивов. Причём цена перехода огромная, никто бы этого просто так делать не стал

disarmer ★★★
()

Первое. Если о точках монтирования на момент старта системы ничего не известно (т. е. не описаны в fstab) — зависимости от них указать нельзя, RequiresMountsFor= не сработает ( i_gnatenko_brain, disarmer). Вместо этого можно добавить нужный юнит в зависимости к юниту монтирования (динамически создаваемому).

/etc/systemd/system/my-cool-directory.mount.d/start-my-unit.conf:

[Unit]
Wants=my-unit.service
Before=my-unit.service

Но это изготовление троллейбуса из буханки хлеба. Вероятно, проще будет тупо сделать systemctl start my-unit.service из твоего post-up скрипта.

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

Второе. Действия перед запуском — если они не вписываются в систему зависимостей и директивы Condition*= — придётся делать через самописный скрипт и указывать его в ExecStartPre=.

Соответственно, действия при остановке (штатной) нужно указывать в ExecStop=, а действия после остановки (любой, в т. ч. падения) — в ExecStopPost=.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от disarmer

Не корми тролля. Пожалуйста. Ни к чему загаживать нормальный тред с техническим вопросом.

intelfx ★★★★★
()
Ответ на: комментарий от i_gnatenko_brain

А теперь, представь, что тебя так будят. ;) Still wanna it?

beastie ★★★★★
()
Ответ на: комментарий от intelfx

Спасибо за пояснения, направление, куда копать понял. Пока что на скорую руку сделал скриптами перед и после остановки, но надо ещё подумать. Смотрю в сторону варианта с разнесением по разным юнитам.

shell-script ★★★★★
() автор топика
Ответ на: комментарий от shell-script

скриптами перед и после остановки

Имхо, так вполне приемлемо, если всё работает (а должно, раз работало исходно).

Если ты хочешь сделать полностью аккуратно — то стоит добавить нужную тебе точку монтирования (sshfs-ную) в fstab с параметрами noauto,x-systemd.automount (или nofail вместо обоих, тут уже по смыслу) и _netdev.

И вот уже тогда в сам юнит напиши RequiresMountsFor=/needed/directory и добавь в автозапуск.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.