Об этом вашем прогрессивном systemd.

openvpn

WTF?

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

Ошибка в юните ничем не отличается от ошибки в любом другом конфиге/скрипте, в чём тут виноват системд?

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

Дай угадаю - арч.

Проблема не в инновациях. :3

/thread?

Ничего, скоро Леннарт прикрутит к systemd поддержку libastral. Вот тогда всем наступит счастье, и никто не уйдет обиженным.

Дык ясное дело, сырая поделка. Чего от неё ждать.

Каждый к ней прикоснётся - уже обиженный. Может собирать матрас под шконку.

Ты это, бросай заниматься тем, что у тебя на аватаре.

Ты ссылку на твой баг-репорт забыл. И да, причём тут systemd?

и теперь никогда не будет так, что сетевые демоны фейлятся стартанув раньше сети

А что, в каких-то системах такое было? В том Gentoo в openrc всё в порядке с весьма сложными зависимостями, и прямыми, и обратными. В Ubuntu не ковырялся, но, кажется, такой проблемы тоже не видел.

Да, я тоже заемучался баги в .service файлах выгребать. Особенно когда .service файл зависит например от отдельно смонтированного /var.

Не знаю правильно ли я сделал

# cat /etc/systemd/system/local-fs.target 
.include /usr/lib/systemd/system/local-fs.target

[Unit]
Requires=var.mount
After=var.mount

но вроде относительно глобально всё исправилось.

В этом самая большая боль юнитов: они написаны для неких средних сценариев использования. Если у тебя что-то отличается то ты попал. В лучшем случае можно подправить юнит под свои нужды (это офицальная позиция разрабов systemd). В худшем я писал скрипты которые делали всё как надо.

какого, спрашивается, лешего After=network.target не включено по дефолту

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

На кой ляд нужны все эти технические инновации, если люди их всё равно по-хорошему не используют?

Вы прослушали выступление операционистки бабы Гали на тему «карандаш и бумажка против этих ваших кантуперов».

На кой ляд нужны все эти технические инновации, если люди их всё равно по-хорошему не используют?

Арчепроблемы. В нормальных дистрах все сделано как надо.

но какого, спрашивается, лешего After=network.target не включено по дефолту?

Это надо спрашивать в багтрекере у того, кто писал дефолтные конфиги в твоем дистрибутиве. Я серьезно.

https://bugs.archlinux.org/task/35089

кстати ты не думал, что network.target подразумевает уже запущенный openvpn, чтобы программы которые этот таргет хотят нормально работали через впн?)

Арчепроблемы. В нормальных дистрах все сделано как надо.

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

Два чая этому господину.

ТС, сейчас многие пакеты мигрируют, работы у мейнтейнеров много. Глаз замылился, вот и пропустил нечаянно.

WTF?

Что вызвало такую реакцию?

Ошибка в юните ничем не отличается от ошибки в любом другом конфиге/скрипте, в чём тут виноват системд?

Топик-то именно о том, что system ни при чём. Не является инит узким местом в надёжности и удобстве работы системы, и не являлся до появления systemd.

В худшем я писал скрипты

А вот до системдэ этот самый «худший случай» с необходимостью написания скриптов был _всегда_.

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

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

Безалаберность? В арче?
Вот так новости!!!

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

Например вот так, из коробки:

# cat /etc/systemd/system/multi-user.target.wants/openvpn@.service
[Unit]
Description=OpenVPN Robust And Highly Flexible Tunneling Application On %I
After=syslog.target network.target

[Service]
PrivateTmp=true
Type=forking
PIDFile=/var/run/openvpn/%i.pid
ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf

[Install]
WantedBy=multi-user.target

Ну, допустим, да. Какое это имеет отношение к системе инициализации, имеющей дистронезависимые .service-файлы, поставляющиеся апстримом?

И да, причём тут systemd?

Ставим вопрос шире: при чём тут система инициализации?

Ставь системд, говорили они.

И повелся на это?

А что, в каких-то системах такое было?

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

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

Какой средний вариант использования OpenVPN не предполагает наличия работающей сети?

В лучшем случае можно подправить юнит под свои нужды (это офицальная позиция разрабов systemd). В худшем я писал скрипты которые делали всё как надо.

На будущее.

Или твои претензии к автору конкретного юнита, который к systemd и инновациям никакого отношения не имеет?

This.

Арчепроблемы. В нормальных дистрах все сделано как надо.

Начнём с того, что .service файлы общие для всех дистров, и это было одним из основных доводов в пользу systemd для майнтейнеров. Ну и нехорошо выставлять себя пустозвоном, не приведя пример .service файла из «правильного» дистра в качестве пруфа.

Просто вопрос.

Это надо спрашивать в багтрекере у того, кто писал дефолтные конфиги в твоем дистрибутиве. Я серьезно.

Там столько еды не будет. :-)

И при чём тут прогрессивные технологии? Он мог и в баш-ините не прописать зависимость.

Неправильно. Так у тебя если вдруг /var сдохнет, система даже в emergency.target не загрузится (emergency.target -> sysinit.target -> local-fs.target -> сдохший var.mount).

Надо патчить конкретный сервис; в последних версиях systemd для этого есть drop-in куски юнитов (/etc/systemd/system/foo.service.d/bar.conf) и параметр RequiresMountsFor=<путь>.

кстати ты не думал, что network.target подразумевает уже запущенный openvpn, чтобы программы которые этот таргет хотят нормально работали через впн?)

Кстати, нет. И как в systemd решать эту проблему в общем случае? Я заставил демон ждать старта конкретного профиля netcfg, но это не подходит для всех.

Да, но openvpn сам может являться частью network.target?

Тут уже написали, что в Арче After=network.target тоже включено, но это не помогает. Ещё варианты?

В гугле забанили?

И при чём тут прогрессивные технологии? Он мог и в баш-ините не прописать зависимость.

Вы начинаете понимать.

Интересен авторский комментарий.
Ладно, забей :-)

Какой средний вариант использования OpenVPN не предполагает наличия работающей сети?

openvpn-клиенту она для старта не нужна. Как только сеть появится туннель сам поднимется. Серверу который слушает на 0.0.0.0 сеть тоже не нужна.

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

Мне рассказать в лицах что такое VPN и для чего он нужен?

А вот до системдэ этот самый «худший случай» с необходимостью написания скриптов был _всегда_.

Проблема в том что эти все юниты уж слишком замороченные. Они как бы не ЯП, поэтому логики туда особой не засунешь. С другой стороны, там есть 100500 разных директив. Вот ты помнишь хотя бы треть man systemd.service? Мне каждый раз чуть ли не заново его приходится перечитывать. И это только один мануал из 313.

Имхо, правка и отладка юнитов это большая боль.

Серверу который слушает на 0.0.0.0 сеть тоже не нужна.

Вот этого не знал.

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

Вот ты помнишь хотя бы треть man systemd.service?

Неа)