> Либо экран Вам поболее, либо память получше. Склероз в таком юном возрасте...

Экран довольно большой, а возраст не такой юный как хотелось бы. Не отменяет антипатий к спагетти-коду вместо аккуратной компактной конфигурации.

> Естественно слезает, ведь он запускает BASH портянку.

1) типовой юнит ничего не запускает кроме сервиса. Системд умеет все что надо типовому сервису сам.
2) Bash в стартовых скриптах обычно не используют, если мы про это. Сразу видно практикующего эксперта. Совсем не палится на мелочах.

> Если нужно что-то сложнее, то 30+ строчек кода в юните обычное дело, но куда нам до
> лаконичности запуска хеловорлдов

В шелскриптах кроме параметров еще и всякий обвес и того хуже - логика. Для себя я как програмер считаю смесь кода и его конфигурации антипаттерном.

> в документации стыдятся написать подробно обо всех подводных камнях?

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

> Имхо, Вам бы поучиться, чтобы понять, когда код, когда конфиг, а когда
> логика декларируется.

ИМХО я так то програмер, и не факт что хуже вас. Поэтому могу оценить что вижу. И могу не оценить менторский тон. Как-то так.

> Если сравнивать, что половина логики задаётся декларативно в unit-е,
> половина в скрипте запуска и это повсеместно, то, как по мне,
> лучше всё-таки всё в одном файле, чем в 3х?

Поэтому в 95% случаях и есть только unit-файл. Типовому сервису - выше крыши. Даже с продвинутостями типа изоляции от системы, затяжки секурити каким-нить SECCOMP, основательно кастомизированый и минимизированый доступ в систему (приватный темп, кастомный вид фс, ...).

> Только написанное в мане подходит для самых простых случаев, шаг в сторону
> -- неопределённое поведение в лучшем случае.

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

> В худшем - отваливается другая часть системы инициализации. Про параметры
> окружения я вообще молчу.

Я собираю кастомные образа систем. В том числе с сервисами которых нет в репах и даже с моими собственными. Удачи в рассказах что там у меня якобы отваливается. А вот скрипты я намаялся отлаживать когда все вроде ок, при тестовом пинке от рута пашет, а при реальной загрузке тишина. И в логах фигвам. Но вы можете накодить логинг сами. Ага, всю жизнь мечтал. Хотя мечтал я вообще-то побыстрей запустить мой кастомный сервис, а не с системными проблемами без логинга бодаться.

> Может, если хорошо попросишь у кого нужно. В почтовой рассылке.

Гарри поттера за меня уже попросили вон те эмбедеры на Linux Plumbers Conf, тот услышал их. За что им там всем спасибо, мне тоже в тему было. Это намного круче чем рассказы что мне должно быть (не)нужно и прочий BS.

> тащит и запускает SystemD, видимо, не влияют на скорость.

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

> Волков бояться, в лес не ходить. Вы, наверное, часто запускаете контейнеры на
> 100ТБ по несколько ТБ ОЗУ в прод?

Нет, конечно. Но мое окружение состоит из мелких железок, мелких виртуалок, контейнеров и UML чуть менее чем полностью. Да, я пользуюсь современными технологиями. Хоть и не в хипстерском виде. Поэтому минимальный демьян может и 30 метров весить на все - и тем не менее это полноценная копия системы, независимая от других. Продвинутые технологии типа CoW и KSM могут даже сделать так что на них не аллоцируется полный объем места на диске или RAM. Чудеса дедупликации - эн виртуалок занимает меньше места в RAM и на диске чем вес виртуалки * N. И я умею в эту магию. Приятно же "оверселлить" и "оверкомитить" самому себе, со знанием дела.

> Тогда из-за чего переживаете про взлом?

Потому что интересуюсь секурити. И поэтому хочу чтобы было удобно мне и неудобно - атакующим. Изоляция от системы и урезание привилегий софту очень в тему.

> Фантазии...

Я довольно интересный фантазер. Который сбилдил чертову кучу кастомных образов систем, себе и клиентам. Маленький нюансик.

> Если да, то я тоже такого хочу, но убожество, которым является
> SystemD -- это явно не тот случай.

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

> Ну а если Вы действительно уверены в том, что SystemD панацея, пожалуйста,
> напишите два юнита:

Он не "панацея". Но очень полезный союзник как по мне.

> 1. U1 работает и поддерживает сервис для U2

Шелскриптеры норовят хрень сделать начиная с формулировки хотелок. Что значит "поддерживает сервис для U2"? Предоставляет некие услуги которыми пользуется U2? Например как вебсервис (U2) использует SQL (U1)? Я правильно понимаю общую идею?

> 2. Запуск U1 вещь затратная и его запуск занимает существенное время

И чего? Необходим лимит рестартов в случае сбоя? Лимит числа рестартов? Какая-то специфичная реакция на сбои? Или... ? Спецификация не полная.

> 3. U2 не может работать без U1

"Не может работать" - хреновая спецификация проблемы. Как минимум...
1) Я так понимаю что важен порядок старта. Т.е. U2 после U1, и это скорее "жесткое" требование, нежели мягкое (т.е. пуск U2 только после того как U1 отсигналит что готов?).
2) Из этой спецификации не понятно что произойдет с U2 если U1 помер и/или что надо делать с U2 если U1 помер. Скажем, надо ли U2 принудительно остановить если U1 не работает? И какая реакция если

> 4. После запуска U2 должен с использованием U1 отрапортовать об успешном запуске.

Что значит "с использоваинем"? Статус запуска трекается системд. И с его точки зрения есть статусы тех или иных юнитов. Ну и глобальный статус системы, основанный на том есть ли сейчас проблемные юниты. Для своих сервисов можно пользоваться апи например вачдога через которое можно более детально сигналить системде некоторые вещи. Если надо что-то сверх того это уже сервисы между собой должны разбираться сами через свои апи или что там у них, имхо.

> Я бы назвал эту ситуацию как 2 сильно связанных сервиса.

Да вроде обычная ситуация.

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

Если работа U1 стала невозможной, U2 очевидно не может работать, по вашим же условиям. Но совершенно не сказано какая должна быть реакция системы на подобное событие. Может, до того как хотелки выдвигать, стоит научиться в их нормальную спецификацию хотя-бы?