Ты просто туп и не понимаешь гениальности и дальновидности разработчиков. Systemd используется «из коробки» во всех популярных дистрибутивах и ни у кого из разработчиков не возникало такого глупого вопроса.

Осознай свою никчёмность и проникнись мощностью, универсальностью, гибкостью, да что скромничать — гениальностью этого передового программного продукта!

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

Лол, склонен согласиться :)

Штеудфх, какой юзкейс этого ключевого слова? Когда юниты жёстко зависимы друг от друга, но без привязки к порядку старта/останова?

Require переводится как «требовать», никакого «требовать чтобы ещё вчера было готово» там нет, это только неасиляторам снится.

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

Именно так, для определения порядка нужно использовать After=

Это ещё ладно, порядок хотя бы можно определить. Я вот в Qt Quick/QML недавно копался так там вообще:

http://doc.qt.io/qt-5/qml-qtqml-component.html#completed-signal

The corresponding handler is onCompleted. It can be declared on any object. The order of running the onCompleted handlers is undefined.

:(

Например, тогда, когда порядок обратный. Или когда два юнита напрямую не взаимодействуют, но поодиночке смысла не имеют. Или когда логика ожидания запуска кастомная. Или когда используется сокет-активация (тогда порядок запуска не имеет значения), но нужно отваливаться при падении второго компонента.

Юзкейсов много бывает...

Например, тогда, когда порядок обратный.

Тогда B req A, а не A req B, не?

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

Это как?

Или когда логика ожидания запуска кастомная.

Ну разве что.

Require переводится как «требовать», никакого «требовать чтобы ещё вчера было готово» там нет, это только неасиляторам снится.

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

Для спуска в шахту нужна веревка, вы пока без веревки спускайтесь, а веревку мы вам потом сбросим.

Required для работы вообще

Ну, они видимо имели в виду, что required нужен во время работы, но во время старта можно и без него обойтись.

кто вообще выпустил разработчиков из зоопарка.

Неизвестный гей в руководстве Redhat.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm

(philisoraptor) А может Redhat - это тот же Apple?

Зачем так усложнять логику?

Systemd используется «из коробки» во всех популярных дистрибутивах

Потому что его туда пропихнули бюрократическими интригами.

и ни у кого из разработчиков не возникало такого глупого вопроса.

Потому что никто не мог толком понять как systemd работает. А те кто мог понять, либо сами разработчики systemd, либо опасались ненависти безумных фанатов systemd.

Это как?

мне в голову приходит веб-сервис на произвольном порту + проксирующий nginx

Например, условный постгрес и условный скрипт, который его мейнтейнит время от времени. Requires= они оба друг друга, а зависимость порядка только в одну сторону.

разделяю негодование топикстартера

Requires= они оба друг друга,

с какого перепугу, постгрес без этого скрипта как-нибудь проживёт

Ну и что ты не понял?

After - например приблуда X стартует после запуска постгрес, поскольку юзает его. Значит у этой приблуды в After=postgresql

Required - эта приблуда не работает без постгрес. Значит если кто-то останавливает постгрес (в процессе работы, а не старта), сначала останавливаются все кто зависит от постгреса, потом только выполняется останов постгрес.

Там все написано, не вырывай фразы из контекста.

А если не проживёт?

Нет, Requires= без After=/Before= означает, что никто никого ждать не будет (ни при запуске, ни при остановке).

Required - эта приблуда не работает без постгрес. Значит если кто-то останавливает постгрес (в процессе работы, а не старта)

Если приблуда не работает без постгреса, с чего бы ей запускаться раньше него?

Например, условный постгрес и условный скрипт, который его мейнтейнит время от времени. Requires= они оба друг друга, а зависимость порядка только в одну сторону.

Т.е. если скрипт сдохнет, сдохнет и postgres? Какая-то неправильная логика.

P.S. Не говоря уже о том, что такое проще сделать через cron.

означает, что никто никого ждать не будет (ни при запуске, ни при остановке).

Да они оба остановятся. Тогда сильно непонятное «нахуа»?

Requires=
Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

Если приблуда не работает без постгреса, с чего бы ей запускаться раньше него?

Вобщем-то тут я в тупике.

Required - эта приблуда не работает без постгрес. Значит если кто-то останавливает постгрес (в процессе работы, а не старта), сначала останавливаются все кто зависит от постгреса, потом только выполняется останов постгрес.

Прочитай ещё раз:

Note that requirement dependencies do not influence the order in which services are started or stopped.

Так вопрос именно об этом. И логика в этом если и есть, то особая, потерианская. Чертовы инопланетяне.

И логика в этом если и есть, то особая, потериинская.

Может просто не осилили разруливаение циклических зависимостей?

Я что-то понять не могу, тебе эта опция жить мешает? Что-то ты в своем стремлении найти в системд ну хоть какой-нибудь изъян уже совсем в какие-то дебри залез.

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

Прочитай ещё раз:

Прочитал. Пробежался по всей доке. Вообще интересно

Тут есть

Required=
After=
Before=
Wants=
...

:D

В следующих версиях ждем

DoNotWants=
IHadPMS=
IHadHeadashes=

Я что-то понять не могу, тебе эта опция жить мешает? Что-то ты в своем стремлении найти в системд ну хоть какой-нибудь изъян уже совсем в какие-то дебри залез.

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

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

Да я бы с радостью, но в новом доебане (на котором основан proxmox) systemd.

Что-то ты в своем стремлении найти в системд ну хоть какой-нибудь изъян уже совсем в какие-то дебри залез.

Ты пробовал пользоваться systemd или за тебя всё мейнтейнеры дистра сделали?

Выбери систему инициализации по вкусу

Есть такое понятие, как «целевая платформа». Менять на ней компоненты вроде системы инициализации нельзя.

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

крон

А если скрипт парсит логи и что-то по ходу подкручивает в настройках, то через крон не сделаешь.

Т. е. ты хочешь сказать, что такой необходимости никогда ни у кого возникнуть не должно?

Я хочу сказать, что я его не вижу. Мб кто-то сможет мне рассказать.

А если скрипт парсит логи и что-то по ходу подкручивает в настройках, то через крон не сделаешь.

Это ещё почему?

И IHumblyAcceptLennartAsMyMaster. Пока не установишь в True, ничего не работает.

Я как пользователь написал себе один кастомный юнит.

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

необходимости запускать вместе с сервером какого-нибудь обязательного клиента этого сервера?

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

Клиент всегда стартует после, сервера

Совершенно верно. И именно поэтому Requires= имеет смысл применять как в паре с After=, так и в паре с Before= или вообще без зависимости порядка.

If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated.

что непонятно? по дефолту они стартуют одновременно - голубая мечта многих быдлокодеров 8)

Я хочу сказать, что я его не вижу. Мб кто-то сможет мне рассказать.

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

Сейчас у постгреса есть свой собственный супервизор, который это делает. Но если предположить, что постгрес выкинет его в пользу systemd, то от основного (гипотетического) юнита постгреса к юниту autovacuum будет именно такой набор зависимостей: Requires и Before.

А если скрипт парсит логи и что-то по ходу подкручивает в настройках, то через крон не сделаешь.

Это ещё почему?

Ну, наверное, потому что иногда (как в вышеприведённом случае) бывает нужно следить за чем-то в реалтайме.

И именно поэтому Requires= имеет смысл применять как в паре с After=

Тут не идет речи, о том как применять. В документации написано. Тут толксы и речь идет о целесообразности. Одной директивы require достаточно, чтобы выстроить граф запуска, в конечном итоге при циклической зависимости, можно поворчать в лог с просьбой «уточнить порядок запуска» и стартануть конфликтующие ветки одновременно. Но тут сделано точно наоборот.

отмечусь

за тебя всё мейнтейнеры дистра сделали?

А чем им еще заниматься, как не связывать лоскуты в дистрибутив?

Ты пробовал пользоваться systemd

Да. Как разработчику, очень нравится, что пары строк в юните достаточно для простого демона. И сам демон прост, тупо спамит в stdout и stderr логи. Этого хватает для немонстрообразных демонов.

«journalctl -f» опять же, давно ожидаемая мной фича, еще со времен первых openwrt, где я это увидел (там аналог «logread -f») - без лишнего головняка получаешь трейс системы.

Но. Язык юнитов довольно убог, что печально. И похоже, это надолго. Всякие такие головняки, как ТС описал - так же считаю недостатками (еще можно вспомнить infinity vs. 0 в таймаутах). Хотелось бы более понятной и прозрачной работы.

По совокупности, это нравится больше того, что было в centos-5, debian-5, под которые приходилось деплоить мне как разработчику, а не как специально выделенному админу.

Я тебе пытаюсь растолковать, что иногда нужно выразить обратный порядок запуска, т. е. в некоторых случаях приходится использовать Requires= в паре с Before=. А иногда упорядочивать запуск вообще не нужно, достаточно стартануть одновременно. Поэтому по умолчанию одно не подразумевает другое.

Ну вот возьмём тот же постгрес. Там есть такая штука, как autovacuum. При этом его недостаточно запускать просто по расписанию, есть ситуации, в которых его обязательно запускать, иначе случится потеря данных.

Шо?

Все правильно сделано

Возьмем два процесса: база данных и клиент базы данных (какое-нибудь api сервер). По твоей логике клиент должен запускаться строго после базы данных, раз уж ему она нужна для работы.

Только вот что база данных, что клиент не первой строчкой кода приступают к взаимодействию. База данных может при старте проверять как там ее файлы, целы ли, не поврежден ли журнал и т.п. Точно так же клиент при старте может что-то делать, не требуя БД, или содержать логику, вообще от бд не зависящую (пинг, статус, покажи схему типа данных X и т.п.).

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

man 'transaction id wraparound'

конечно, обработка 4 миллиардов транзакций это обычное дело на любом локалхосте. на практике же autovacuum часто вообще выключают и выполняют по крону vacuum вместе с другими вещами.

А чем им еще заниматься, как не связывать лоскуты в дистрибутив?

Я об этом не спрашивал. Если тебе интересно - найди разработчиков и спроси.

Как разработчику, очень нравится, что пары строк в юните достаточно для простого демона. И сам демон прост, тупо спамит в stdout и stderr логи. Этого хватает для немонстрообразных демонов.

То есть взаимозависимых демонов ты не писал?

Я сказал: такие ситуации есть. Когда именно они есть, меня не волнует. Важна принципиальная возможность.

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

Ну так это postgres requires autovacuum, не?

Я тебе пытаюсь растолковать, что иногда нужно выразить обратный порядок запуска

Обратный порядок запуска? Ты точно понимаешь о чем мы говорим?

т. е. в некоторых случаях приходится использовать Requires= в паре с Before=

Нет. Зависимость либо есть либо ее нет.

А иногда упорядочивать запуск вообще не нужно

Ну вот оно и стартует параллельно, без необходимости лишних сущностей.