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

Кто сказал?

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

В какой ещё конфигурации по умолчанию? Нет никакой конфигурации по умолчанию. Я проектирую свои системы грамотно.

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

да я уже понял

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

Тут такое дело, если это разовая задача, смысл писать к ней морду? Только пустая трата времени. И даже если многоразовая/эпизодическая, но исключительно «для себя любимого».

Какая-то синтетика, если честно. Я думал, это история из жизни.

Например какой мне смысл писать морду для задачи которая что-то возьмёт в БД, посчитает и результат положит в БД или в какой-нибудь файлик?

Если это длительная и критичная задача - то для контроля исполнения, не?

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

Редкие выхлопы можно отправлять пользователю любым доступным способом. Без необходимости заходить на сервер и что-то менять. Ну и да, кто сказал Application Performance Monitoring?

Какая-то синтетика, если честно. Я думал, это история из жизни.

История из жизни и не единичная. Было дело, приходилось данные крутить.

Если это длительная и критичная задача - то для контроля исполнения, не?

Для разовых задач не всегда имеет смысл. Если не отвалилась, значит работает, вот и весь контроль.

в твоём арсенале только лозунги

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

сертификат по заббиксу

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

Ну все-таки пока не полностью.

да ты посмотри на это новое поколение админов.:(

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

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

Говорю же — так сильно пытался выставить меня дураком, что случайно выставил дураком себя. И так этого и не понял, по ходу. ;)

знал, что зацепит

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

Отнюдь. Просто смешно

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

Ты предложил мне забить гвоздь гаечным ключом

Ну дык, конечно. Я-то раньше с этой ситуацией сталкивался не один раз. А ты вот начинаешь лозунгами говорить... гвоздь... ключ... «Неправильная задача»! Теперь она «этим инструментом» не решается! Теперь нужен новый инструмент! Не удивлюсь, если она в старых книжках по администрированию описана. Но нет, умный intelfx слишком умный для таких задач.

Говорю же — так сильно пытался выставить меня дураком, что случайно выставил дураком себя. И так этого и не понял, по ходу. ;)

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

systemd банально контролирует большее количество сущностей...

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

В какой ещё конфигурации по умолчанию? Нет никакой конфигурации по умолчанию.

эт все прекрасно, но это не функции init'a.

История из жизни и не единичная. Было дело, приходилось данные крутить.

То есть, это какой-то «свой» сервер, на котором крутится только эта задача, и ходит туда только тот, кто её запустил? А не юзеры, что бы папочки помонтировать.

Для разовых задач не всегда имеет смысл. Если не отвалилась, значит работает, вот и весь контроль.

Для критичной задачи контроль всегда имеет смысл, независимо от разовости.

«Неправильная задача»! Теперь она «этим инструментом» не решается! Теперь нужен новый инструмент!

Да. Всё так. Ты забыл написать, почему это плохо.

Меня-то это вообще не волнует.

Если бы тебя это вообще не волновало, ты бы не переходил на личности каждые полтора сообщения.

<…> ты начал умничать <…> я тебя обломал <…>

ЧТД.

это не функции init’a

Ты уже не знаешь, за что ухватиться. Кто сказал, что мы обсуждаем инит? Мы обсуждаем systemd.

Ты уже не знаешь, за что ухватиться.

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

Кто сказал, что мы обсуждаем инит? Мы обсуждаем systemd.

а что такое systemd?

а что такое systemd?

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. Other parts include a logging daemon, utilities <…> and daemons <…>

(c) https://www.freedesktop.org/wiki/Software/systemd/

ну да, я его фреймворком называю. но функции инит он ведь _тоже_ выполняет?

а вот, как это выглядит в солярис по UNIX way:

https://www.oracle.com/technetwork/articles/servers-storage-admin/f1-1729179.gif

В цитате и по ссылке всё написано.

а вот, как это выглядит в солярис по UNIX way

От того, что там напихали лишних сущностей, более или менее «юникс веем» оно не стало.

От того, что там напихали лишних сущностей, более или менее «юникс веем» оно не стало.

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

А напомни мне, если в SMF падает корневой исполнитель (я забыл, как там по терминологии), то что происходит? И насколько велика разница между перезагрузкой системы и перезапуском всех прикладных процессов? Но зато инит не упал, такое-то достижение.

Я же с самого начала сказал: у тебя инит священная корова. Ты втемяшил себе в голову лозунг «инит не должен падать!!11» и не видишь за ним вообще ничего.

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

по моим понятиям «корневой исполнитель» у них тоже меньше по кодовой базе, чем systemd. нет у него функций fuse монтирования и пр. Если он упал, то моя «священная корова» его перезапустит и он к какому-то там более или менее консистентному состоянию (в рамках того, что должен) систему выведет. Мой поинт, что хотя там возможно и нет какой-то прямо мега интеграции по общей шине, как в systemd, но процессами эта хрень управляет. конфигурируется стандартно, т.е. скриптов, которые ты не любишь, меньше. А инит всеравно сделан тупым, чтобы никаких данных не принимать. Понимаешь, в твоей схеме с systemd-вочерами не понятно, за ними-то кто будет смотреть. И вот этот-то прокол в дизайне собственно и сказался в сабже.

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

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

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

Чем это отличается от перезагрузки системы?

Чем это отличается от перезагрузки системы?

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

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

Но при чём тут KISS и количество процессов? Такой дизайн будет работать вне зависимости от того, один там процесс на всё или несколько.

Но при чём тут KISS и количество процессов? Такой дизайн будет работать вне зависимости от того, один там процесс на всё или несколько.

при том, что svc.startd даже писать в эту базу сервисов не может, за это отвечает другая утилита и UNIX way как раз и состоит в таком вот раздельном дизайне, разделении функций: меньше функций, много маленьких утилит.

И это всё абсолютно не важно.

очень философское высказывание. это все, что ты хочешь сказать по сабжу?)

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

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

Вот ты сейчас разбрасываешься словами, смысла которых не очень понимаешь.

Что значит «нарушает целостность данных»? Где здесь «безвозвратно»? Мы что-то делали, затёрли себе стек, упали (мы же собираем софт с канарейками? правда?), поймали сигнал, перезапустились, перечитали базу с диска. Её можно вообще на всякий случай не держать открытой, а записывать из дочернего процесса после форка, можно много чего делать.

будь даже конфиг состояний на диске (он и так ведь на диске изначально)

Нет, на диске только конфиг. А состояние — не на диске, оно только в памяти.

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

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

Где здесь «безвозвратно»?

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

можно много чего делать.

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

Нет, на диске только конфиг. А состояние — не на диске, оно только в памяти.

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

Ты точно читал тут юзкейс? Когда крипт предлагал сколько-то там гигов логов обрабатывать прямо на самом сервере?

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

Непонятного примерно всё. Ты уже третье сообщение с термином определиться не можешь, просто умными словами кидаешься. Нарушена целостность данных? Или программы? А данных каких? Если мы затираем стек, то нарушается целостность данных в памяти. А по нашему предположению всё состояние сериализовано на диске.

Во-вторых, если мы затираем стек, то мы просто детерминистично падаем, потому что мы собираем софт с канарейками. Ну, это мы, новомодные недоадмины. А ветераны юникса, возможно, об этом просто не знают.

ты жмешь reboot

Опять споришь с воображаемым собеседником. Не буду тебе мешать в этом занятии.

теряешь SLA по всем сервисом на этом сервере

А ты точно знаешь что такое «SLA»?

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

мы просто детерминистично падаем

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

и мы не падаем

Сильное заявление. Неужели найден первый в мире софт без багов?

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

я не пойму, что ты пытаешься у меня выяснить?

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

Зато ты не понял, что я хочу сказать.

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

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

Я вроде с самого начала сказал — я признаю, что у SMF архитектура лучше за счёт вот этой вот сериализации. Но за счёт сериализации, а не за счёт всяких там KISS и юниксвеев, которые ты себе выдумал.

она как раз за счет UNIX way лучше. потому что монтирование fuse лежит отдельно и не может вызвать порчу памяти важного процесса.

Нет. Перечитай последнюю страницу, я прекрасно это обосновал.

Ты зацепился за монтирование fuse и продолжаешь про него талдычить. Не fuse, так что-нибудь другое способно уронить SMF, я в этом на 146% уверен. Дело же не в этом.

что происходит с остальными процессами в случае креша systemd, как в сабжевом примере?

Они продолжают жить.

Не fuse, так что-нибудь другое способно уронить SMF, я в этом на 146% уверен.

это вопрос размера attack surface. вроде бы это очевидно. systemd настолько раздут, что возможности, видишь, находятся. если у нас функционала мало (я напоминаю, svc.startd - это рестартер), возможностей меньше. неужели нужно писать такие очевидные вещи? и это принципиальное преимущество UNIX way.

Нет никакого принципиального преимущества, устал уже тебе объяснять. Отказоустойчивые системы — это не те, которые сложно уронить, а те, которые могут это пережить.

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

что происходит с остальными процессами в случае креша systemd, как в сабжевом примере?

Они продолжают жить.

я только что прибил systemd на Fedora 33 и вся виртуалка просто зафризилась. она не отвечает по сети. она не регагирует в окне vbox. (перед этим я проделал тот же фокус с svc.startd). да, в systemd встроили игнор kill -9, но эт не помеха:Е)

Отказоустойчивые системы — это не те, которые сложно уронить, а те, которые могут это пережить.

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

Зашёл почитать про приколы с memcpy и прочим, почитал срач про systemd.

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