Так хорошо поругал systemd, что даже похвалил.

sergej

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

Axon

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

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

Версия системд такая:

# systemctl --version
systemd 204
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ

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

То есть, асинхронный старт юнитов не наводит вас на мысли причине разного поведения?

Причем тут systemd?

Это мейнтейнера пакета с openvpn нужно бить по лицу

Кривой юнит :-)

В fedora всё нормально:

[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

Это мейнтейнера пакета с openvpn нужно бить по лицу

Да мы тут как-то уже не уверены, что так уж нужно. Каково ваше мнение по вопросу?

Кривой юнит :-)

В fedora всё нормально:

Дочитайте тред. :-)

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

А вообще хорошая заметка. Действительно могут быть сервисы, которые должны работать с сетью через VPN, а следовательно должны дождаться его запуска.

Ну так создать в /etc потомка нужного сервиса и указать ему, что он должен ждать vpn

initscripts-fork себе хочешь ты, юный падаван

Как пример: У нас есть:

• Сервис с именем myservice.service
• OpenVpn с именем myopenvpn

Нужно пускать этот сервис после этого vpn.

Создаём «потомка» сервиса вот с таким содержанием:

#Подключаем "предка"
.include /usr/lib/systemd/system/myservice.service 
[Unit]
After=openvpn@myopenvpn.service

 systemctl disable myservice && systemctl enable myservice

Должно сработать.

что network.target подразумевает уже запущенный openvpn

Уже запущенный через астрал openvpn ? :-)

офигеть.. как люди с этим живут?

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

systemd делался для того, чтобы сервисы подходили ко всем дистрам. И мне systemd фанбои говорили, что такой проблемы не может быть никогда..

P.S. похоже я с прогнозом где-то на полгода-год ошибся, я думал, что позже такая хрень начнется.

systemd делался для того, чтобы сервисы подходили ко всем дистрам. И мне systemd фанбои говорили,

И чем unit федоры не подходит арчу? Или просто пукнуть зашёл?

P.S.: По хорошему openvpn не должен входить в network.target, если общий доступ к сети осуществляется не через него.

И чем unit федоры не подходит арчу?

этот вопрос ты должен задавать не мне, а мейнтенеру арча. Более того, ответ на него совершенно не важен, т.к. в данном случае важен только факт того, что в арче не использовали unit от федоры. Т.е., что тот _якобы_ бонус, который дает systemd не используется.

P.S. Если ты хочешь вести нормальный диалог, забудь про выражения типа «пункуть решил и т.п.».

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

Еще больше в копилку ненависти.

этот вопрос ты должен задавать не мне, а мейнтенеру арча.

Юнит совместим. А то, что майнтенеру арча всё нравится делать самому, это арче-проблемы.

P.S.: Я с удовольствием не буду использовать такие выражения, но тогда, пожалуйста, не подменяй понятия не подходит (в ключе не совместим) и не используется. Здесь нет ни намёка на несовместимость.

Слова «фанбои» в «нормальном диалоге» тоже быть не должно, если что.

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

возьмите EL, там systemd еще нет пока и все работает. Есть линукс для энтерпрайза, есть для энтузиастов.

Systemd «ненужен ». Ставь OpenRC/SysVInit!

Вы не уловили месседж.

Есть линукс для энтерпрайза, есть для энтузиастов.

А если я именно энтузиаст?

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

Цель системд - общие юниты на всех, эта цель не выполнена, даже в дистре прямом последователе Федоры. Это факт. И постепенно ситуация будет ухудшаться (скорее всего). Почему это уже отдельный вопрос.

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

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

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

юзеры системде начинают подозревать что их обманули

вот так сюрприз

Арчепроблемы.

Цель системд - общие юниты на всех, эта цель не выполнена

Да. И она никогда не будет выполнена, т.к. всегда найдётся кто-то, кто захочет что-то сделать по своему. Майтенеры не исключение.

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

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

Ну как сказать.. иниты с LSB header обладают тем же свойством + могут запускаться в. bsd-rc, sysv-rc, openrc (с 0.12). У них правда есть куча других проблеи таких как многословность и большие возможности (как следствие больше способов сделать одно и тоже).

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

В том, что его адепты всё вещают про «само будет работать как надо»

иниты с LSB header обладают тем же свойством + могут запускаться в. bsd-rc, sysv-rc, openrc (с 0.12).

Я думаю, что переносимость других инитов тема для отдельного разговора. Насколько я понял, мы выяснили, что у systemd нет проблем с переносимостью unit'ов между дистрами?

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

Пффф... Во-первых, я никого конкретно не обвиняю, а констатирую проблему. Во-вторых, увижу, что кто-то делает херню, так и буду говорить. Сюсюканье и лицемерие тоже комьюнити ни фига не укрепляет.

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

systemd не умеет в телепатию, и автоматически создавать зависимости между сетевыми интерфейсами не то чтобы вообще возможно. Если демоны не умеют адекватно реагировать на динамически меняющуюся «картину сети», как dnsmasq — то задача расстановки зависимостей ложится на плечи админа, и это нормально.

А как же тогда работает systemd-nspawn? Либо это 4.2, либо ты что-то делаешь не так.

Юниты (если не имеют багов) по умолчанию подходят ко всем дистрам, соответствующим неким стандартам (на семантику .target-юнитов, на иерархию ФС, и т. д.). Если какой-то дистрибутив патчит программу, чтобы она работала в нестандартном для неё окружении — то пусть патчит и юнит. Разве это не логично?

А вообще хорошая заметка. Действительно могут быть сервисы, которые должны работать с сетью через VPN, а следовательно должны дождаться его запуска.

Это какие-то неправильные сервисы. Даже RIP/BGP демоны так работать не должны.

Слова «фанбои» в «нормальном диалоге» тоже быть не должно, если что.

LOR wat r u doing? LOR stahp!

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

Разумеется. Вот в том же Debian вместо systemd стоит sysvrc.

А я смог в systemd. Против апстрима переть намного накладнее, чем читнуть слегка манцов. Правда от этого он нужнее не стал, да.

systemd-nspawn запускает контейнер из хост ос. Задача запустить ось с systemd в lxc контейнере в системе, где нет systemd.

LSB-инит скрипт (если не имеет багов) по умолчанию подходят ко всем дистрами и разным системам управления сервисами, соотвествующими неким (LSB) стандартам. Разве не логично? При всем моём неуважении к LSB и инитскриптам с LSB заголовком, данную задачу они решали лучше.

Где, кстати можно почитать _стандарт_ «unit совместимую» на систему?

Логично. И в чём проблема? Есть $network в LSB-заголовках скриптов, и есть network.target в systemd. Разницы никакой, только в одном случае топологическую сортировку делает хз кто в статике, а во втором systemd в рантайме. В чём LSB лучше?

// man bootup и доки на fd.o

А, окей.

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

Просто я хотел сказать про то, что унифицированность unit не то, чтобы огромный прогресс, и (имхо) получается большей частью за счет наличия основного контрибьютора (fedora project) и «урезанности» [1] возможностей. При этом со временем вес основного контрибьютора может падать, а «урезанность» возможностей приводит к тому, что иногда людям приходится пилить свои скрипты.

[1] говорить «урезанность» не коррентно, т.к. у systemd функциональность шире, под урезанностью я имею ввиду, что юниты это декларативный и не сильно выразительный DSL.

Первый вопрос: зачем тебе arch?
Второй вопрос - зачем systemd используют там, где он не нужен?

IMHO пока армия юзеров Ubuntu не отбагрепортит systemd, всё так и будет.

Есть же debian в установке с sysV, есть gentoo, calc и слака... Там нет секса, если ты не любишь извращения.

У меня такое было с autotunnel. В юните тоже написано

After=network.target

After=dhcpcd.service

UPD: наврал. Т.к. у меня сервис фейлился из-за отсутсвия сети, я там просто прописал:

Restart=always
RestartSec=30sec