>> 1. Если я не понимаю, кто запустил какой-то процесс, то мне обычно
>> хватало простого pstree, хоть он и не всегда помогает, конечно.
> Ну вот вижу я процесс которому parent'ом PID=1. И дальше что? То
> что у него PID=1 parent'ом - отнюдь не доказывает что его
> init запустил. И? Очень зависит от.

Повторяю:

> хоть он и не всегда помогает

А вообще, всё зависит от конкретных обстоятельств. В худшем случае существуют audit-ы, fanotify-и; или если человек не способен даже на первые два и совсем не понимает, что происходит, то может смастерить разовый костыль вроде подмены конечного приложения скриптом «pstree > /root/pstree.out». Но почему-то мне никогда не приходилось ничем таким страдать даже на абсолютно чужих системах, хотя активно работаю с Linux ещё с 2.4. Проблма какая-то высосаная из пальца.

>> А  вообще не припомню, чтобы это было проблемой.
> А мне вот не нравится размазня по куче мест в конфигурации.

Разные задачи решаются разными приложения. Не нравится это? Нравится когда ставится большой bundle а-ля MS Windows, где DE [MS DWM] является неотделяемой частью ОС?

>> 2. А с установленным systemd всякие rc.local-ы, inetd, cron-ы, at-ы и т.п.
>> неработоспособны уже что ли?
> В половине случаев нет и rc.local уже.

И что вместо него? Далеко не раз помогал при отладке различных удалённых систем.

>> На своей системе у меня нет проблем разобраться что к чему очень быстро и удобно
> Я и говорю - удобно для админов локалхоста.

Я не про localhost говорил. А про production системы на текущей и предыдущей работах.

> А для продакшна, где
> передача браздов правления машиной нормальная практика это уже не айс.

Почему это? Это вопрос лишь документирования и разъяснений при передаче обязательств. Я так и не увидел в чём проблема.

> Да
> и в плане руления локалхостом я предпочту видеть все что касается
> старта процессов и прочих VM в каком-то одном месте а не
> дюжине закоулков, говоря начистоту.

А я предпочту иметь систему, где каждую задачу выполняет своё приложение. Где я свободно могу конструировать такую систему, которая под мои задачи хорошо подходит. А не мириться в bundle-ами, где всё решили за меня.

>> А на чужой системе чем systemd спасёт? Запретит rc.local?
> Ну не "запретит" жестко, но - сделает obsoleted. Например upstart без слоя
> совместимости - вообще его выполнять не собирается.

Его легко можно туда впилить. И если админ хочет использовать rc.local, он это легко и быстро сделает и на systemd, и на upstart (ну либо systemd/upstart — такое говно, что там нельзя такое сделать легко и быстро). А следовательно вопрос тут только лишь культуры администрирования и документирования, а не централизации причин запуска приложения. Другими словами, systemd тут ничем не поможет…

> Так что в половине
> систем или надо вкатывать добавочный хлам, или использовать конфиг-файлы. Мне вот
> такой подход к дефолтам сильно более симпатичен. Вывести окаменелый крап в
> obsoleted. Без шума и пыли, оставив совместимость для тех кому ну
> вообще крындец как надо, но не приветствуя все это в дефолтах.
> Чтобы на практике исчезло у всех кроме наиболее принципиальных и в
> продакшне не попадалось.

Я rc.local активно использую для отладки удалённых систем. Например, была удалённая система, у которой почему-то интерфейс поднимался на секунду, а потом падал. Если в rc.local его передёрнуть, то the интерфейс снова поднимался. А учитывая отсутствие в той серверной IP-KVM-а и отсутствия лицензии на iLO, сохранять ssh-доступ при перезагрузке в процессе отладки данной проблемы мне очень помогало. И нужно это ровно до тех пор, пока не отлажу чёртову проблему. Но тратить своё время каждый раз включая rc.local (а иногда случайно узнавая лишь при перезагрузке, что он не сработал и отлаживаемая система недоступна) — это как раз «не айс», как вы выражаетесь.

По поводу "размазанности запуска" всё очень просто. Либо вы урезаете функционал (который имел свои use case-ы), либо объединяете в один bundle (что ущемляет свободы выбирать как решается конкретная задача чисто технически), либо комбинируете эти варианты, либо оставляете как есть.

Общаясь в 100 раз на эту тему просто убеждаюсь, что systemd — это Дон Кихот, который бежит на ветряную мельницу. Решаются лишь какие-то совершено надуманные проблемы… Есть действительно положительные вещи у systemd, но если бы systemd был просто init-ом, то тогда они бы стоили того во многих use case-ах, а так — нет.