> Ну ты попробуй, расскажешь о результатах.Я то попробую если не забуду. (Может для этого напишу статью на HH как это сотворить и что из этого вышло.)
>А у меня нет желания с этим возится, мне проще убрать systemd оттуда, где он вызывает проблемы.
Это на текущий момент(учитываю то что у вас был Bad XP) нет желания.
> У меня есть масса куда более интересных занятий в свободное время.
Пример, DIY, или программирование, или написание комментариев, или статей, или свой вариант.
> А самое главное, мне в большинстве случаев без разницы из-за чего у systemd проблемы со штатными сервисами дистрибутива.
А мне нет. Поскольку если стоит проблема которая может привести в будущем к россыпи всего что было сделано раньше, это носит характер немедленной корректировки работы сервиса.
> Пусть у ментейнеров болит голова по этому поводу.
Если будет проблема у мейнтейнеров, то эта проблема перескочит и на нас с вами. Так что нет, появилась проблема у мэйнтэйнеров решаем её и помогаем развивать дистрибутив дальше.
> Я же просто получу нужный мне результат здесь и сейчас, даже если для этого придется превратить юнит systemd в пускалку "портянки".
> Любопытно, возня с системой инициализации как важная часть админской работы появилась только с появлением systemd, до него этому вопросу уделялось ничтожно мало времени.
Эта возня идет как раньше первым делом и когда меняется софт или мажорная версия этого софта с проскоком всех минорных версий. (Спасибо, но не хочу как раньше перечитывать и переписывать часть скрипта если вдруг он отвалился после апдейта.)
> На этом фоне особо смешат рассказы его сторонников про облегчение работы админа.
Ок, может вас и смешат эти рассказы, но меня нет, мне реально проще редактировать просто сервис указав его переменные среды и команду и не думать что он запустится от рута и не сломается на ходу.
> Ну а я наблюдал как при running и отсутствии ошибок в том куске, что выводит status, в реальности нужного процесса не наблюдалось.
Последние версии SystemD следят за процессами запущенными им, наверное поэтому я и не видел этих проблем.(Сейчас на версии 235.38 я не вижу этих проблем и до этой версии(с момента установки ArchLinux) ну не замечал подобного поведения он всегда(с момента установки ArchLinux) работал исправно.)
> Хотя справедливости ради, я такое видел не только с systemd, но и с upstart.
Повторюсь такого поведения не замечал на SystemD, а вот насчет Upstart я предпочту забыть, спасибо.
> А какое отношение initramfs имеет к системе инициализации, кроме одинакового названия для файла, запускаемого ядром?
> Задача initramfs заключается в загрузке модулей ядра, необходимых для монтирования корневой fs и возможно еще каких-то действиях перед передачей управления собственно иниту.
> Использовать полноценный init внутри initramfs конечно можно, но смысла обычно нет.
Смысл в том что:
1. Это хоть не на много но позволяет передвинуть момент когда /sbin/init будет запущен;
2. Чтобы провести восстановительные работы перед подключением RootFS.(К примеру, сегфолтящаяся либа в RootFS. Я это встречал на Ubuntu 16.10 когда она была ещё нестабильной.)
> Ну тебе уже ниже приводили пример файла конфигурации сети, без всяких ручных вызовов ifconfig, iwconfig, dhclient, brctl и прочего.
Я знаю что это можно сделать и без этого.
> Нет, всё равно упорствуешь.
Из-за непонимания. Куда бросить и где создать и с каким шаблоном по имени.
> Вот тебе еще пример
> [\CODE]
> auto lo
> iface lo inet loopback
> auto br0
> iface br0 inet dhcp
> bridge-ports eth0 regex veth.*
> [\/CODE]
Пример бесполезно приводить я его видел не раз.
> И о чудо, работает черти сколько лет без всякого systemd.
Именно что без SystemD и связки его с udev это будет работать. А после добавления этой связки(именно связки в не отконфигурированном состоянии) `bridge-ports eth0 regex veth.*` превратится в тыкву потому-что eth0 не существует, но вместо него существует enpXsY[.Z].
> Какой-то очень странный логический вывод.
Потому-что я пытаюсь доказать что SystemD имеет право на существование там где это возможно.
