Немного Марсианской Логики

net - это что? Если аналог network-online.target, то vpn сам должен быть его частью. Если это сервис, то какой из возможных вариантов?

в таком варианте будут сопли когда народ захочет несколько зависимостей перечислить, хотя если делать так:

Requires = foo.service(parstart=no), bar.service(parstart=yes)

то можно достичь даже большей гибкости

и чсх это можно встроить даже в имеющийся синтаксис

Можно и так. Но это всё проектирование, которое должен был выполнить поцеринг.

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

для остальных есть Before

net - это что? Если аналог network-online.target, то vpn сам должен быть его частью. Если это сервис, то какой из возможных вариантов?

Это сервис, предоставляющий сеть. И нет, vpn не должен быть его частью, потому что vpn'у нужна сеть для работы (сюрприз). Это любой из сервисов, дающих тебе доступ в сеть.

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

И это отлично показал пример nginx, которому нужна была точка монтирования, которую делает proxmox, шоп сертификаты забрать. Или ты предлагаешь прокси-серверу тупить на inotify пока файл не появится?

Не могу придумать пример, работа которго отличается при «After=b\nRequieres=b» от «After=b»

Если сервис A.service After B.service, но не Wants и не Requires, то при systemctl start A.serice B.service не запустится.

Если A.service After B.service, и при этом A.service Requires B.service, то при systemctl start A.serice B.service запустится.

И это отлично показал пример nginx, которому нужна была точка монтирования,

на любого программиста найдется юзер-извращенец, ты можешь еще нжинкс навесить на сетевую фс, а сеть зарулить через прокси этого самого нжинкса, и рассказывать нам потом как все плохо 8)

на любого программиста найдет юзер извращенец, ты можешь еще нжинкс навесить на сетевую фс, а сеть зарулить через прокси этого самого нжинкса, и рассказывать нам потом как все плохо 8)

Зачем? Здесь точка монтирования — fusefs, которая предоставляет конфигурацию proxmox в файловом виде. Довольно удобно.

P.S. Алсо я не вижу проблемы. Иногда один и тот же ресурс монтируется через iscsi на несколько разных сервисов, например. С общей хранилки.

Ок. Неправильная формулировка. Не незапустится, а либо остановится/либо незапустится.

просто ты ты это просрал
Так да? Дерзкий парень?

Ну да. А что не так?

Зачем? Здесь точка монтирования — fusefs,

ЧИТД

ЧИТД

Пока никто ничего не доказал :)

Теория про то что «для любого программиста, найдется хотябы один юзер-извращенец».

Ну да. А что не так?

Что логика нормальных людей подсказывает: если сервис *ТРЕБУЕТСЯ*, он будет запущен раньше, а не в случайный момент времени. Единственный use-case, который тут придумали, это intelfx с его autovacuum. Но это, ИМХО, притянуто за уши, ибо их проще сделать одним юнитом.

Теория про то что «для любого программиста, найдется хотябы один юзер-извращенец».

Ммм... Нет, пока что не доказал. Как я уже сказал, пример с iscsi приведет к ровно такому же поведению.

юзер-извращенец

не доказал. Как я уже сказал, пример с iscsi

Что характерно для извращенцев, они свое поведение считают нормой 8)

Я както еще наблюдал персонажа который пытался grub на рейд поставить. Ставит - граб не видит свой раздел - оно не запускается, «ну все же так делают»! и так неделя. Спас я его воткнув в недра сервера тупую флешку с /boot.

Что характерно для извращенцев, они свое поведение считают нормой 8)

Прости г-ди, а хранилки данных-то тебе чем не угодили?

Ты про любые?

Это любой из сервисов, дающих тебе доступ в сеть.

А что будет, если таких сервисов два? (например, network.service + NetworkManager в centos) Кто из них будет net? Ну это, так, ради праздного любопытства.

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

Алсо, если у тебя основной интернет через vpn, а vpn сам стартует после net, то правильно я понимаю, что все остальные, кто ждёт net смогут запуститься до vpn, когда рабочей сети ещё нет?

Ты про любые?

Я про SAN.

Всем угодили, мне не угодили перцы которые пытаются с них грузиться.

А что будет, если таких сервисов два? (например, network.service + NetworkManager в centos) Кто из них будет net? Ну это, так, ради праздного любопытства.

Они оба говорят:

provide net

Поэтому запустив любой из них ты получаешь доступ в сеть. Easy.

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

Алсо, если у тебя основной интернет через vpn, а vpn сам стартует после net, то правильно я понимаю, что все остальные, кто ждёт net смогут запуститься до vpn, когда рабочей сети ещё нет?

Да. Следовательно, тебе стоит им сказать, что на самом деле они хотят VPN. В systemd это можно сделать проще?

Что логика нормальных людей подсказывает

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

Ты не забыл, что при падении требуемого юнита твой юнит тоже упадет?

Совсем не обязательно. Например, какой-нибудь сервис будет работать без почтовика, просто не сможет кидаться письмами. Если это не критично - пусть запускаются параллельно.

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

Я знаю, что в доках написано. Это не делает логику менее марсианской.

Совсем не обязательно. Например, какой-нибудь сервис будет работать без почтовика, просто не сможет кидаться письмами. Если это не критично - пусть запускаются параллельно.

В доках написано, что совсем обязательно.

В системд сервисы хотят network-online.target (так-то это тот самый net в openrc, за небольшими отличиями). vpn, в случае, если он основное соединение, должен быть частью этого network-online.target, (и по логике именно он должен provide net в openrc).

Так что тут либо переделывать зависимости всех сервисов, хотящих net (network-online), либо переписывать vpn.

А в системд, как видишь, можно обойтись простым after в vpn.service.

В системд сервисы хотят network-online.target (так-то это тот самый net в openrc, за небольшими отличиями). vpn, в случае, если он основное соединение, должен быть частью этого network-online.target, (и по логике именно он должен provide net в openrc).

Так что тут либо переделывать зависимости всех сервисов, хотящих net (network-online), либо переписывать vpn.

А в системд, как видишь, можно обойтись простым after в vpn.service.

Ммм... Мб здесь стоило разделить net на physical-net и net, да. Мб стоит заслать патч.

Сынок, тебе сколько стукнуло?

Мне показалось, или за ответ на некорректное с меня только что сняли -2 шкворца?

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

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

Нет, для этого есть After= и Before=, против которых я ничег против не имею.

Не показалось.

Не показалось.

Вай? Я ему тонко намекнуло, что у него толсто.

Автоматика.

Автоматика.

tВИМ!

Единственный use-case, который тут придумали, это intelfx с его autovacuum. Но это, ИМХО, притянуто за уши, ибо их проще сделать одним юнитом.

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

Если сервису А нужен Б, но он может подождать его запуска, то должно быть просто Requires.

Если сервис А должен запускаться строго после Б (не умеет ждать), но сам Б для него необязателен, то либо просто After, либо After + Wants, по ситуации.

Если сервису А необходим Б, и он должен запускаться строго после Б (не умеет ждать), то только тогда нужен After + Requires.

Проведи аналогию с асинхронным программированием.

Нет, для этого есть After= и Before=

Ну так мы про них и говорили, вроде.

Ну так мы про них и говорили, вроде.

Не знаю о чем гооворил ты, а я про Require=, который не определяет порядок :)

Если сервису А нужен Б, но он может подождать его запуска, то должно быть просто Requires.

Вот это-то для меня и странно, потому что здесь имеет место быть race condition, если сервис плохо ждет. А в большей части случаев сервис плохо ждет.

P.S. Простой пример: sshd, который слушает на 0.0.0.0 или на 10.10.10.1. В первом случае тебе пофиг на поднятые интерфейсы, а во втором у тебя sshd не сможет прицепиться к адресу, но будет висеть в памяти. Т.е. в зависимости от адреса тебе нужен либо Requires=, либо Requires= + After=.

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

И я весь топик пытаюсь понять, зачем она нужна в случае наличия After или Before. В доке написано: ортогонально.

Так что, ты немного не туда влез.

Так что, ты немного не туда влез.

Нет, это тебя куда-то не туда понесло. Чувак спрашивал, зачем нужна Requires=, если у тебя уже есть After=. А ты ему начал залечивать, как сделать VPN'ы через After= без Requires=.

Вот это-то для меня и странно, потому что здесь имеет место быть race condition, если сервис плохо ждет. А в большей части случаев сервис плохо ждет.

Если сервис плохо ждёт, то считай, что он не умеет ждать. Это далеко не всегда так.

Простой пример: sshd, который слушает на 0.0.0.0 или на 10.10.10.1. В первом случае тебе пофиг на поднятые интерфейсы, а во втором у тебя sshd не сможет прицепиться к адресу, но будет висеть в памяти. Т.е. в зависимости от адреса тебе нужен либо Requires=, либо Requires= + After=.

Он будет висеть только до поднятия соответствующего интерфейса, ибо requires. Если интерфейс зафейлится, то системд погасит ssh.

А если интерфейс поднимется, то ssh займёт адрес. При этом, параллельно с поднятием интерфейса он сможет прочитать конфиг, проверить/сгенерировать ключи и сделать все другие необходимые ему дела.

Чувак спрашивал, зачем нужна Requires=, если у тебя уже есть After=.

Зачем нужна requires очевидно, чтобы запускать зависимости. У него был вопрос, почему After этого не делает. По сути вопрос, зачем нужен after без requires. Я на него и ответил.

Он будет висеть только до поднятия соответствующего интерфейса, ибо requires. Если интерфейс зафейлится, то системд погасит ssh.

А если интерфейс поднимется, то ssh займёт адрес. При этом, параллельно с поднятием интерфейса он сможет прочитать конфиг, проверить/сгенерировать ключи и сделать все другие необходимые ему дела.

Нет, не займет, я только что проверил.

Зачем нужна requires очевидно, чтобы запускать зависимости.

Нет, чтобы контролировать их наличие. При смерти зависимости умирает и зависимый.

И это тоже. И это тоже очевидно.

И это тоже. И это тоже очевидно.

Ну раз спрашивает, значит не очевидно.