> но с чего это вдруг всё это находится в *системе инициализации*?

С того что:
1) Упомянутые сисколы требуют определенного порядка вызова и все это должно быть сделано до сброса привилегий.

2) PID=1 находится в правильном месте в правильное время: он может правильно отпедалить всю последовательность сисколов и у него для этого хватит прав.

3) PID=1 запускает мою программу. А третий - лишний. И лишь загромождает собой систему лишними сущностями. Ну то-есть бутлоадер, ядро, стартер и моя программа в системе неизбежно будут. А остальные - как "неизбежное зло". И чем их меньше - тем лучше, в общем случае.

4) Прописать 10 строчек в конфиг системд мне сильно проще и менее криво/проблемно чем использовать месиво из дюжины разных утилит + дописывать граблеопасный системный код самому вместо поттера.

Де факто мне нужна системная программа которая дернет пачку сисколов в правильном порядке и отдаст моей программе руль (через "exec*") уже в нужном состоянии. Системд как раз и является таковым. В крайнем случае я ессно могу и свой костыль написать, но лениво изобретать велик на ровном месте, знаешь ли.

> Перечисленный Вами функционал не относится к ней ни разу,

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

> и многими этими задачами занимаются отдельные демоны в userspace.

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

> Учитывая, что мы разговариваем не о ядре, как тут втесалось слово realtime?

Ну вот так вот и вписалось - man sched_setscheduler. Ну и sched_setparam заодно. Это не hard realtime, но мне в ряде случаев - хватит.

> Это Вы так SCHED_FIFO или SCHED_RR называете, что ли?

Они так называются в официальной документации и это до некоторой степени отражает суть. Кстати, пользуясь случаем - передаю большой факофф тем кто стандарт на POSIX THREADS принимал.

> Зачем же говорить, что "система сыровата, и у неё отваливаются критичные сервисы".

Ты в своем праве писать свои программы. Лучше и без багов, зарулив меня в хламину. Если сможешь. А если в случае факапа кому-то придется перть за тридевять земель и это будет стоить приличных денег - поневоле подстрахуешься.

Заодно не забудь купить radiation-hardened процссор. Правда он стоит как самолет. И сделать трехкратное резервирование, по мажоритарному принципу. Пусть все будет как для полета в космос, тогда будем считать что железо сбойнуть "не может". Ну правда и стоить будет как три самолета. И не факт что столько готовы платить за земные применения (за такую сумму дешевле будет там поселить кого-нибудь ресет нажимать в случае факапа).

> перезапуск отвалившихся критичных сервисов". =)

Ну, понимаешь, в некоторых задачах факапы разруливать реально некому. Поэтому just in case - они должны быть разрулены самой девайсиной, настолько насколько это вообше возможно. А идеальный мир без ошибок и сбоев - это круто, но - не про планету Земля и ее жителей.

> Вы не поверите, но shell-скрипты в sysvinit всё это могли.

Я не поверю. Из них сисколы дергать напряжно. А уж вачдог какой-нибудь из них делать... ненене, Дэвид Блейн. Это ты как-нибудь сам, без меня.

> А когда этот не-гемор навернётся, Вы познаете, почему многие админы считают

Я уже узнал прямо вот тут что эти "многие админы" оказывается не в курсе что такое sched_setscheduler. Скажи честно, ты про SCHED_RR и _FIFO узнал целых 5 минут назад, из мана? Ну или откуда столько глупых вопросов?

> т.н. "гемор" несколько лучшим вариантом.

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

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

> Ибо покопаться-поискать ошибку в скриптах в разы легче, чем в монстроузной systemd.

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

А скажи, чувак, сколько ты будешь сношаться с переписыванием своего скриптошита, если задать небольшое но забавное требование: ну вот допустим что файловая система у нас readonly. Журналов и лога - нет. Есть только /dev/kmsg. Systemd ткнуть в него как в место для логгинна - пара директив. И логи через syslog() туда же можно сбагрить. А ты что с твоей скриптятиной будешь делать в таком раскладе?

> Постоянно только о том и разговор.

ЧСХ в основном у тех кто системд не пользуется.

> встречается у всех фанатов systemd.

Ну так я и говорю - ты можешь сделать лучше. И зарулить меня. Если сможешь. Правда вот это не факт, глядя на твои заявы про реалтайм...

> Да уж. Зачем делать сервис, который не падает?

Наверное, потому что в любой достаточно сложной программе всегда есть шанс наличия невкусных багов. Поэтому мне хочется иметь "план Б" на случай если факап все-таки произошел. Чтобы было поменьше предъяв, и вообще. Я в реальном мире живу. И поэтому в курсе что в софте бывают баги, случаются ошибки, и вообще, мир неидеален.

> как и повесить на watchdog. Новое поколение программистов.

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

> почему GNU/Hurd всё ещё не готов.

Ну вот поэтому я и пользуюсь GNU/Linux. Потому что крутой, замечательный, мегаконцептуальный но почти неработоспособный и напрочь непригодный для моих задач Hurd мне ни в п...у, ни в красну армию. Ты можешь им пользоваться наздоровье.

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

> А, плохому танцору... =)

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