root в ядре и обрушение системы через systemd (local)

Гыгы. Всякая бабуйня в стеке nodejs несколько лет под виндой не собиралась из-за путей > 1500 знаков.

Да нет, просто после патча ядра два дня назад перестал вешаться ROCm OpenCL на AMD, но также перестал работать tensorflow. Наверно, это хорошо, потому что теперь всё работает так, как обещали разрабы ROCm, а не случайным магическим образом...

Как бы ты тут не совсем прав. Слабосвязные системы таки действительно надежнее, т.к. отказ одного из компонентов не вызов отказа всей системы (в общем случае). Понятно, что тут есть своя обратная сторона, но тем не менее.

Я пытаюсь донести, что «KISS» тут никакой роли не играет — правильную отказоустойчивую архитектуру можно построить вне зависимости от следования всяким там идеалам юникса, даже в полностью монолитной системе.

Ну все-таки KISS в монолите сохранить сложнее. Ааа мне сейчас только запустить побыстренькому, потом перепишу... и т.д. и т.п.

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

Ну да, конечно... Монолитный, сильно-связанный код...безусловно лучше, чем вероятность сломавшегося шурупчика в юниксвей. И вероятность получить баг в монолите меньше чем в kiss. А уж точек соприкосновения в монолите в 100500 раз меньше... правда-правда.

тогда выходит windows 95 был очень отказоустойчивой системой))) его тогда все перезагружали раз в час, и он, гад, смог это пережить)

Вы забыли маленькую, но очень важную деталь упомянуть «и переставляли раз в неделю». «Пора переустанавливать шиндоус...ко-ко-ко...», никаких ассоциаций не вызывает? :)
Кстати в каждой шутке, есть доля шутки. У меня например копия свежего инстала 95-й с офисом &etc просто лежала на соседнем диске, в случаях «опять навернулась» тупо форматировался диск и копировалась «свеже установленная». :)

А вот такие мы не предсказуемые :)

Вы забыли маленькую, но очень важную деталь упомянуть

на самом деле это очень похоже на современные парадигмы с использованием контейнеров от rh/федоры:) полезные данные лежат отдельно, а сам контейнер disposable и даже обновления по сути являются переустановкой. и все это обмазывается трехэтажными рассуждениями о надежности и отказоустойчивости.

p.s.

ты же раньше на ты со всеми был. и ты же тоже когда-то солярисом занимался. или память подводит?

p.p.s.

и копировалась «свеже установленная».

дада, все эти трюки были очень популярны.)

я только что прибил systemd на Fedora 33 и вся виртуалка просто зафризилась. она не отвечает по сети. она не регагирует в окне vbox

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

тогда выходит windows 95 был очень отказоустойчивой системой))) его тогда все перезагружали раз в час, и он, гад, смог это пережить)

Как ты там сказал… «если ты не хочешь, чтобы я считал тебя за глупого собеседника, не нужно косить под дурака». Ты тоже прекрасно понимаешь, что я хочу сказать.

По каким-то критериям надёжнее, по каким-то критериям менее. Слабосвязные системы — широкое понятие.

и все это обмазывается трехэтажными рассуждениями о надежности и отказоустойчивости.

Очень хорошо подмечено!

ты же раньше на ты со всеми был. и ты же тоже когда-то солярисом занимался. или память подводит?

Скорее подводит. С соляркой я вынужденно сталкивался. И хоть не раз и не два, но это было давно и не правда, последний раз не позднее 2006-го.

дада, все эти трюки были очень популярны.)

Ну нязнаю насчет популярности. Среди моих знакомых ни одного такого изобретателя не нашлось. Да и в ftn сетях такое «популярное» не пробегало. Все мужественно продолжали «переустанавливать шиндоуз».

Что значит «нарушает целостность данных»?

у нас запись за границы буфера. нарушена целостность самой программы. что здесь не понятного?

Так вы уж определитесь или целостность данных или целостность запущенной программы.

Так вы уж определитесь или целостность данных или целостность запущенной программы.

в каком-то смысле все, что находится в памяти - это данные (data). компьютер вообще машина по работе с данными (data). переполнение идет в стеке (содержит data), но могут быть повреждены объекты vmalloc.

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

ты решил учиться у меня риторике?:)

Ты тоже прекрасно понимаешь, что я хочу сказать.

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

pam_systemd не отвечает

и на пинг тоже...

Не могу воспроизвести.

кто бы сомневался. зато зарепортившая проблему команда может. поэтому-то у меня и зацепились твои слова. (мы что одни в треде? пусть кто-нибудь еще попробует и напишет на какой системе и оформит в code свои действия.)

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

но могут быть повреждены объекты vmalloc

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

«Объекты vmalloc», чтобы ты знал, находятся в пространстве ядра. Из пространства пользователя к ним нет никакого доступа, тем более на запись.

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

Нет, просто ты как обычно меня переврал.

я тебе четко это показал

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

и на пинг тоже

А напомни-ка мне ещё раз, что мы обсуждаем и что конкретно ты сделал?

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

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

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

Слушай, да ты же вообще не понимаешь, о чём говоришь. Просто перетасовываешь умные слова в надежде, что наблюдатели поразятся твоим глубоким знаниям и не заметят. «Объекты vmalloc», чтобы ты знал, находятся в пространстве ядра.

 if an attacker FUSE-mounts a long directory (longer than 8MB), then systemd exhausts its stack, crashes, and therefore crashes the entire operating system (a kernel panic).

...However, the attacker may corrupt other vmalloc()ated objects instead (for example, thread stacks), but we have not investigated this possibility.

блаблабла. по факту нечего возразить, да?

и подгон задачи под ответ.

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

Нет, просто ты как обычно меня переврал.

ну конечно. бедный ты наш непонятый. вечно тебя все перевирают. сволочи!:(

А напомни-ка мне ещё раз, что мы обсуждаем и что конкретно ты сделал?

ты сказал, что креш systemd не влияет на другие процессы, также, как и в старом дизайне (пример с Solaris svc.startd). но оказалось, что ты не прав. креш systemd делает машину недоступной. я это и сам вижу на тесте (прибил systemd), это же и у исследователей по ссылке. см. выше. (тут ты начинаешь бодро убеждать всех, что это ничего, что у нас отказоустойчивость и можно быстро все перезагрузить начисто). в то же время с svs.startd сервисы продолжают работать дальше. а сам svc.startd, если его прибить, перезапускается инитом, вычитывает состояние с диска and live happily ever after.

Это вообще о двух разных уязвимостях (вторая в ядре), гений.

по факту

По факту ты несёшь бред, прикрываясь умными словами и хождением по кругу. На бред возражать бесполезно, можно только констатировать его наличие.

ты сказал, что креш systemd не влияет на другие процессы, также, как и в старом дизайне (пример с Solaris svc.startd). но оказалось, что ты не прав. креш systemd делает машину недоступной. я это и сам вижу на тесте (прибил systemd), это же и у исследователей по ссылке. см. выше. (тут ты начинаешь бодро убеждать всех, что это ничего, что у нас отказоустойчивость и можно быстро все перезагрузить начисто).

Что такое «креш», конкретно? Если вручную вызвать смерть PID 1 (любого), то машина станет недоступной, вот это поворот. Осталось только выяснить, при чём тут systemd.

Когда systemd падает естественным путём (сигнал 6 или 11), срабатывает обработчик этого события и systemd превращается по сути в sysvinit (ну или падает до конца, это настраивается). Установить обработчик SIGKILL нельзя (и не нужно, т. к. он никогда не присылается автоматически). Если твой тест заключался в kill -9 1, то я тебя поздравляю — ты балбес.

в то же время с svs.startd сервисы продолжают работать дальше. а сам svc.startd, если его прибить, перезапускается инитом, вычитывает состояние с диска and live happily ever after.

Да, вот только это заслуга не юниксвея или какого-то ещё «старого дизайна», а совсем другой архитектуры. О чём я тебе и сказал — отказоустойчивые системы не те, которые не падают (т. к. уронить при желании можно всё, в том числе и svc.startd, и systemd, и скриптолапшу, просто разными методами), а те, которые после этого восстанавливаются.

Нет никакой проблемы в том, чтобы применить концепцию самовосстановления из SMF к монолитному коду systemd. Просто это никому оказалось не нужно, уж таковы времена. Проще ребутнуться.

Что такое «креш», конкретно?

в сабжевой новости, что такое креш конкретно?

Если вручную вызвать смерть PID 1 (любого), то машина станет недоступной, вот это поворот. Осталось только выяснить, при чём тут systemd.

ты забыл про маленькую незначительную деталь: в systemd это оказалось возможным из-под обычного пользователя:) хорошо, покажи мне такую же штуку для sysvinit и модули sysvinit (ой! у него же нет модулей).

(т. к. уронить при желании можно всё, в том числе и svc.startd, и systemd, и скриптолапшу, просто разными методами), а те, которые после этого восстанавливаются.

ну ок. урони pid 1 в солярис. из-под юзера. с использованием уязвимости в том же pid1-процессе. и постарайся не прыгать с темы на тему. svc.startd не pid1.

Когда systemd падает естественным путём...

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

Нет никакой проблемы в том, чтобы применить концепцию самовосстановления из SMF к монолитному коду systemd. Просто это никому оказалось не нужно, уж таковы времена. Проще ребутнуться.

как в windows 95?^) а если бы это закончилось не отказом в обслуживании, а возможностью code exec?^) или так не бывает?:)

p.s.

Просто это никому оказалось не нужно, уж таковы времена. Проще ребутнуться.

Когда systemd падает естественным путём...

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

в сабжевой новости, что такое креш конкретно?

Меня не волнует сабжевая новость, я сейчас говорю конкретно о твоей попытке доказать непонятно что. «Постарайся не прыгать с темы на тему» (c)

покажи мне

урони

Возражения по существу аргумента будут, или опять начинаем перевод стрелок и хождение вокруг да около? Напоминаю аргумент: если вручную вызвать падение PID 1 отправкой неперехватываемого фатального сигнала (чего на практике не бывает), система упадёт. Это свойство ядра Linux. Как данное упражнение связано с systemd или с темой разговора?

в контексте новости

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

или так не бывает?

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

я всегда думал

Не льсти себе.

цитирую: «Нечего сказать — переходим на личности? ... На этом месте уже в принципе слив засчитан. Но я всё-таки отвечу на остаток сообщения, потому что я сегодня с утра добрый.»

root в ядре и обрушение системы через systemd (local) (комментарий)

Меня не волнует сабжевая новость

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

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

Я тебя правильно понимаю, что по-твоему новость ошибочна? Проблема зарепорчена неправильно, systemd должен получать sigabrt или sigsegv и обрабатывать эту ситуацию? То есть по-твоему опять «исходные данные не верны»? И как следствие, отрицая проблему (notabug), ты отказываешься отвечать на вопрос про init. Мол, раз systemd не упала, то и нет смысла опровергать, что init не содержит подобных проблем. Все правильно?

Ах да, еще ты утверждаешь, что даже если init сам по себе и надежнее, чем systemd, то это всеравно несчитово, потому что можно свалить svc.startd. И хотя это не pid 1, будет перезапущен init'ом и не несет таких последствий как перезагрузка и остановка сервисов, то всеравно неважно. Потому что никому сейчас не нужно сокращение downtime'a, а systemd написан из расчета «перезагружать ОС и начать с чистого листа».

цитирую

Если пользоваться данным правилом, ты уже давно слился.

Мне не кажется, что я должен тратить силы на то, чтобы цивилизованно тебе отвечать, учитывая, что ты себя этим явно не утруждаешь.

так ты вспомни, в какой тред тебя пригласили и давай его придерживаться

После вас. Разговор уже давно ушёл в сторону от обсуждения исходной новости, причём с твоей подачи. Требовать от меня, чтобы я внезапно к ней вернулся и не отвечал на твои аргументы — по меньшей мере некорректно.

Я тебя правильно понимаю, что по-твоему новость ошибочна? Проблема зарепорчена неправильно, systemd должен получать sigabrt или sigsegv и обрабатывать эту ситуацию?

Одно из трёх:

• или новость ошибочна (ошибочно подана),
• или исследователи специально настроили systemd так, чтобы он ничего не перехватывал и падал,
• или это баг (недоработка) в механизме перехвата.

И как следствие, отрицая проблему (notabug)

Почему сразу «отрицая проблему»? Bug, конечно.

ты отказываешься отвечать на вопрос про init. Мол, раз systemd не упала, то и нет смысла опровергать, что init не содержит подобных проблем. Все правильно?

Неправильно.

еще ты утверждаешь

Я утверждаю, что проблемы systemd не имеют никакого отношения к «KISS» и юниксвею. Системы, которые достигают отказоустойчивости (SMF), делают это не благодаря тому, что якобы не падают (падает всё, это не требует доказательства), и не благодаря тому, что якобы такие очень простые и юниксвейные, а благодаря вполне конкретным архитектурным решениям, которые при необходимости отлично переносятся на systemd. Почему этого ещё не сделано — вопрос отдельный (на который я тоже ответил: потому что это никому не нужно, се ля ви).

учитывая, что ты себя этим явно не утруждаешь.

я-то нет и никогда не утруждал, но ты сам либо трусы надень, либо крестик сними. это так, на будущее.

Разговор уже давно ушёл в сторону

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

Почему сразу «отрицая проблему»? Bug, конечно.

потому что фактически ты ее митигируешь, придерживаясь

Одно из трёх:

или новость ошибочна (ошибочно подана),

или исследователи специально настроили systemd так, чтобы он ничего не перехватывал и падал,

в оригинальном bug report'e от редхата то же самое. как по-твоему работает redhat security team: берут чужой багрепорт по ссылке, читают токсы на лоре или проводят свое изучение проблемы?

или это баг (недоработка) в механизме перехвата.

этим пунктом ты опять отрицаешь архитектурную проблему. но мнения, что ошибка в перехватчике, я опять же не встречал у вендора. ни поттер, ни редхат так не считают. либо им срочно нужна твоя помощь, либо ты не прав.

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

никакие решения не отменяют простую логику: в сложном продукте выше вероятность ошибки. ты будешь с этим спорить?

на который я тоже ответил: потому что это никому не нужно, се ля ви

это было смешно первых пять страниц. скажи, а почему тогда редхат указывает downtime как негативное следствие этого бага? исходя из твоей логики нужно было писать - негативных последствий нет.

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

О, сисямбда как обычно, что вообще за утро без новостей о ее новых дырах?

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

Проблема в том, что, не разобравшись, «какой сигнал на самом деле получает система», ты эмулируешь не сабжевую ситуацию, а невесть что.

в оригинальном bug report’e от редхата то же самое

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

никакие решения не отменяют простую логику: в сложном продукте выше вероятность ошибки. ты будешь с этим спорить?

Нет. Я буду спорить с неявной предпосылкой, которую ты здесь не упомянул: что systemd якобы «более сложный продукт» чем легаси скриптолапша. Просто сложность разная и проявляется в виде разных типов ошибок. Systemd чаще падает, юниксвейная скриптолапша чаще разваливается и начинает творить непонятно что.

это было смешно первых пять страниц. скажи, а почему тогда редхат указывает downtime как негативное следствие этого бага? исходя из твоей логики нужно было писать - негативных последствий нет.

Нет, ты опять меня переврал. «Никому не нужно» значит, что [по мнению сообщества, не нужно лично мне опять приписывать некомпетентность и вендузятничество] проблема не стоит усилий на её решение, а не что проблемы нет.

затёрли себе стек, упали (мы же собираем софт с канарейками? правда?)

Падение в сабже ведь происходит не из-за затирания адреса возврата (что было бы уязвимостью с вполне реалистичной перспективой исполнения произвольного кода даже при использовании всех сортов канареек — хотя они могли бы затруднить её эксплуатацию), а из-за выхода за участок виртуальной памяти, замапленный как стек, так что падение тут гарантируется тем, что непосредственно перед стеком не лежит страниц, доступных на чтение/запись.

Да, ты прав.

Проблема в том, что, не разобравшись, «какой сигнал на самом деле получает система», ты эмулируешь не сабжевую ситуацию, а невесть что.

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

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

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

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

Нет, ты опять меня переврал. «Никому не нужно» значит, что [по мнению сообщества...] проблема не стоит усилий на её решение, а не что проблемы нет.

Ох же ж ты! Опять слова не слова, это все злой crypt извратил! Нет, ты очень явно высказал свое мнение в самом начале, что лучше перезагрузить (root в ядре и обрушение системы через systemd (local) (комментарий)). И не один раз. И не нужно прикрываться сообществом. Впрочем, это не главное. systemd не была написана сообществом. Поттер просто славится своим отношением... ну да ладно.

Я буду спорить с неявной предпосылкой, которую ты здесь не упомянул: что systemd якобы «более сложный продукт» чем легаси скриптолапша.

Вот это интересно.

1. Если мы берем Solaris init+SMF, то это _бинарные_ компоненты, а не скрипты. С меньшей кодовой базой. У тебя здесь прокол в логике. Это бинарные компоненты и библиотеки.

2. Если мы берем по перечню функционала, то systemd сложнее. Ты предлагаешь подтянуть для сравнения все остальные компоненты UNIX-экосистемы, такие как cron и начать их сравнивать? Но cron не является скриптолапшой. И сам факт такого сравнения говорит о сложности systemd.

Systemd чаще падает

о, ну наконец-то мы приплыли к чему-то. intelfx признал, что systemd чаще падает.

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

Ты продолжаешь упражняться в тупости. Перехват SIGKILL невозможен (и ненужен, поскольку SIGKILL программам автоматически не присылается). Если твой «тесткейс» — это kill -9 1, то ты «тестируешь» невозможную ситуацию и ценность результатов такого эксперимента околонулевая (но тебе не привыкать, да).

Если это дефолтное подведение и не только в их дистрибутиве

Мы теперь фороникс? Мне казалось, что мы обсуждаем архитектурные вопросы и вопросы построения систем компетентным администратором, а не чьи-либо дефолты. А ты опять съезжаешь с темы на то, что тебе в данный момент более удобно.

Нет, ты очень явно высказал свое мнение

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

• Что я говорил в самом начале: «упасть лучше, чем тихо запортить состояние»

• О чём речь сейчас: «в теории можно вообще не упасть, но упасть проще»

Первое — мнё мнение. Второе — статус-кво, который не следует мне приписывать.

Если мы берем Solaris init+SMF, то это бинарные компоненты, а не скрипты. С меньшей кодовой базой. У тебя здесь прокол в логике. Это бинарные компоненты и библиотеки.

А я не говорю здесь про Solaris init+SMF. Опять сам что-то за меня придумал и сам опроверг.

Если мы берем по перечню функционала, то systemd сложнее. Ты предлагаешь подтянуть для сравнения все остальные компоненты UNIX-экосистемы, такие как cron и начать их сравнивать? Но cron не является скриптолапшой.

Скриптолапшой является то, что их связывает. «Все остальные компоненты UNIX-экосистемы» сами по себе абсолютно бесполезны.

ну наконец-то мы приплыли

Не знаю, к чему там вы приплыли. На четвёртый день индеец Зоркий Глаз заметил, что у сарая нет четвёртой стены. В отличие от тебя, у меня не бывает трудностей с признанием чего-либо.

Ну и да:

Опять слова не слова, это все злой crypt извратил

От того, что ты пытаешься иронизировать, это не перестаёт быть правдой. Ты на протяжении всего разговора пытаешься переврать каждое моё слово и подменить каждый мой тезис таким образом, чтобы его было проще опровергнуть. Так что извини (на самом деле нет), я буду называть лопату лопатой.

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

Мы теперь фороникс? Мне казалось, что мы обсуждаем архитектурные вопросы и вопросы построения систем компетентным администратором, а не чьи-либо дефолты. А ты опять съезжаешь с темы на то, что тебе в данный момент более удобно.

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

А я не говорю здесь про Solaris init+SMF. Опять сам что-то за меня придумал и сам опроверг.

заметь, я веду разговор об SMF уже с какой? с третьей страницы? я четко дал понять, что беру в пример. ты такой на пятой странице начинаешь говорить о своем (не уточняя, о чем именно) и потом я опять что-то придумал. это называется «двигать ворота по полю»?

Если твой «тесткейс» — это kill -9 1

да не делаю я kill -9, успокойся уже. игнорирует sytemd его. если бы ты попробовал сам хоть что-то протестить, то знал бы.

Скриптолапшой является то, что их связывает. «Все остальные компоненты UNIX-экосистемы» сами по себе абсолютно бесполезны.

поподробнее, пожалуйста. что связывает крон и init? причем такое, чего нет в systemd. с таким же успехом я могу обвинить systemd в том, что оно позволяет делать вызов последовательности bash-команд в теле своих service файлов. как это там? Exec=cmd&cmd2. <- ой, смотрите, в systemd завелся bash-клей! ужас!

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