В systemd найдена (https://www.openwall.com/lists/oss-security/2019/02/18/3) уязвимость (CVE-2019-6454 (https://security-tracker.debian.org/tracker/CVE-2019-6454)), позволяющая вызвать крах управляющего процесса инициализации (PID1) через отправку непривилегированным пользователем специально оформленного сообщения через шину D-Bus. Разработчики из Red Hat также не не исключают (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-6454) возможность применения уязвимости для организации выполнения кода с привилегиями root, но окончательно возможность такой атаки пока не определена.
Манипулируя размером отправляемого через D-Bus сообщения атакующий может сместить указатель за границы выделенной для стека памяти, обойдя защиту "stack guard-page", суть которой в подстановке на границе со стеком страниц памяти, обращение к которым приводит к генерации исключения (page-fault). По мнению исследователя безопасности, выявившего уязвимость, смещение указателя стека возможно только на неиспользуемые страницы памяти (unmapped), что не позволяет организовать выполнение кода в контексте процесса PID1, но даёт возможность атакующему инициировать крах PID1 с последующим переходом ядра Linux в состояние "panic" (в случае краха обработчика PID 1, происходит крах всей системы).
В systemd устанавливается обработчик сигналов, пытающийся перехватить крахи процесса PID1 (segmentation fault) и запускающий shell для восстановления. Но так как в ходе атаки обращение производится к неотражённым страницам памяти (unmapped), ядро не может вызвать данный обработчик сигнала и просто завершает процесс с PID 1, что, в свою очередь, приводит к невозможности продолжения дальнейшей работы и переходу в состояние "panic", требующего перезапуска системы.Обновления пакетов с устранением уязвимости опубликованы для SUSE/openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2019-6454), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1678394) и частично для Debian (https://security-tracker.debian.org/tracker/CVE-2019-6454) (только для Debian Stretch). Проблема остаётся неисправленной в RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-6454) и Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...). Успешная атака продемонстрирована в Ubuntu 18.10 с systemd 239 и в CentOS 7.6 с systemd 219. В качестве обходного пути защиты может использоваться сборка в GCC c включением опции "-fstack-clash-protection", которая по умолчанию применяется в Fedora 28 и 29.
Следует отметить, что в 2014 году автор системной библиотеки musl выделял (https://www.opennet.me/opennews/art.shtml?num=39050) среди основных архитектурных проблем systemd излишнюю раздутость обработчика PID1 и ставил под сомнение целесообразность реализации обработчика DBus API на уровне PID1, так как он является серьёзным вектором для проведения атак и может негативно влиять на надёжность всей системы.
URL: https://www.openwall.com/lists/oss-security/2019/02/18/3
Новость: https://www.opennet.me/opennews/art.shtml?num=50168
> В systemd устанавливается обработчик сигналов,
> пытающийся перехватить крахи процесса PID1...
> ядро не может вызвать данный обработчик сигнала
> и просто завершает процесс с PID 1Очевидно, для решения проблемы потребуется systemd-kerneld.
А кто тогда будет отрабатывать сегфолты в systemd-kerneld? Не подумали? А ведь это тоже вектор атаки.Для защиты systemd-kerneld от подобного необходимо устанавливать систему в гипервизор systemd-hvd. А для купирования проблемы возможного сегфолта systemd-hvd, прикрутим ему аппаратный systemd-monitd.
В итоге мы получим вполне рабочую систему - за systemd присматривает systemd-kerneld, за которым присматривает гипервизор systemd-hvd, за которым присматривает systemd-monitd. Вот это уже похоже на нормальную систему инициализации, не то, что эти сисвишные портянки.
> А кто тогда будет отрабатывать сегфолты в systemd-kerneld?NOTABUG!
assert спасёт гиганта мысли
+/* Note that the D-Bus specification states that bus paths shall have no size limit. We enforce here one
+ * anyway, since truly unbounded strings are a security problem. The limit we pick is relatively large however,
+ * to not clash unnecessarily with real-life applications. */
+#define BUS_PATH_SIZE_MAX (64*1024)/* Second, add fallback vtables registered for any of the prefixes */
- prefix = alloca(strlen(path) + 1);
+ pl = strlen(path);
+ assert(pl <= BUS_PATH_SIZE_MAX);
+ prefix = new(char, pl + 1);
+ if (!prefix)
+ return -ENOMEMhttps://github.com/systemd/systemd/commit/798ebaf9aea9b8ae3b...
> А кто тогда будет отрабатывать сегфолты в systemd-kerneld?В ядре нет сегфолтов. Там ловушки и прерывания. В данном случае double fault (это отдельный тип - abort, невосстанавливаемая ошибка). При этом юзерланд "сделал всё что мог". Появился повод говорить об ошибке дизайна в ядре. Так что в исходном сообщении не то что бы шутка. Как и в предложении запилить systemd-hvd.
> за systemd присматривает systemd-kerneld, за которым присматривает гипервизор systemd-hvd, за которым присматривает systemd-monitdВо всей этой лабуде уязвимостей не может быть в принципе?
> это уже похоже на нормальную систему инициализацииСломал одно, а остальное посыпется уже само по себе.
Ну то есть смерть PID 1 настолько нормальная ситуация с systemd что они даже обработчик штатный написали. Надёжность!
Отправка сигнала извне это штатная ситуация или нет? Надо ли её предусмотреть и обработать?Другое дело, что в данной ситуации обработчик бесполезен и вынуждает ядро убивать процесс.
Всёравно notabug!1111
> Обновления пакетов с устранением уязвимости опубликованы дляА в devuan исправили уже?
жырно
>> Обновления пакетов с устранением уязвимости опубликованы для
> А в devuan исправили уже?Давно!
25.05.2017 22:51 Первый релиз Devuan, форка Debian без systemd
>> Обновления пакетов с устранением уязвимости опубликованы для
> А в devuan исправили уже?Исправили ещё до первого релиза. Ваш кэп. =)
Там установочные образы год не перестают, так что без этого в диване форменное шерето.
> Там установочные образы год не перестаютПохоже, у нас в гостях или очередной скромный социальный фаззер, или не очень проснувшийся, или просто неграмотный мало-мало... зато специалист по решётчатым!
Это т9. Пересоберут, разумеется.
> Это т9. Пересоберут, разумеется.Где, в логике (точнее, её отсутствии, как в #142 и интересуются)?
А вы после развёртывание образа сразу начинаете пользоваться системой без установки обновлений?
> А вы после развёртывание образа сразу начинаете пользоваться системой без установки обновлений?В необновлённом APT, который их, обновления, и скачивает-устанавливает, с этими самыми скачиваниями есть известная уязвимость.
Debian-ы выпустили "экстренный" поинт-релиз -- в т.ч. установочные CD/DVD с исправленным APT.
У Devuan-а поинт-релизы и исправления .iso-шников "не практикуются".
http://www.opennet.me/openforum/vsluhforumID3/116383.html#44Ресурсов мало, инфраструктура недокручена или ещё что...
...особо невыдержанные анонимы считают, что от этого "в диване форменное шерето". Слабаки[I]!
Да-да, крутые посоны лёгких путей не ищут!
Это безусловно чудесный дистрибутив, исправляющий не только прошлые, настоящие, но даже будущие ошибки systemd.Кстати, Михаил в отдельных сборках ALT тоже превентивно исправил эту и многие другие проблемы системы инициализации с раздутым PID 1.
> Кстати, Михаил в отдельных сборках ALT тоже превентивно исправил эту
> и многие другие проблемы системы инициализации с раздутым PID 1.Это далеко не только моё дело, спасибо коллегам.
PS 2 WSJSoldier: фу так позориться -- фейки разносить.
Дебоян безбажный в принципе, ты чо?
> целесообразность реализации обработчика DBus API на уровне PID1, так как он является серьёзным вектором для проведения атак и может негативно влиять на надёжность всей системы.С одной стороны, а с другой стороны, как я понял из истории этого проекта они хотят иметь всесистемную единую систему IPC/RPC через протокол DBus, которая также должна быть и представлена и в ядре Linux (но патчи пока завернули). Например, чтобы добиться паритета в функциях с той же вендой, но сделать лучше, потому что у венды IPC/RPC это легаси и история. Как обычно, новый функционал = новые уязвимости.
И тут примечательно, почему никто из разработчиков не обращает внимания на такие комментарии. Потому что это предложение НЕ делать чего-нибудь и отказаться от изначальной задачи. Комментарий не предлагает как решить. А как известно не ошибается только тот кто, ничего не делает.
Даже если процессу с PID 1 зачем-то нужно получать сообщения из DBus (что само по себе вопрос), он мог бы их получать через пайп от одного из дочерних процессов уже частично обработанными.
какой еще пайп, вы еще предложите на перфокартах.
Это не стильно, не модно и не молодежно, когда у нас есть libdbus!
> какой еще пайп, вы еще предложите на перфокартах.
> Это не стильно, не модно и не молодежно, когда у нас есть
> libdbus!Не-не, где, панимаишь, REST-http-API в ядре и pid1, когда он нужен!?
это в планах. Не столь отдаленных, хахаха!
> это в планах. Не столь отдаленных, хахаха!Да, понятно. :Q Rest поверх http поверх ip gоверх qr-кодов.
Вот из-за таких как вы BUS1 в ядро и не принимают!!1
> Вот из-за таких как вы BUS1 в ядро и не принимают!!1Спасибо, конечно. Но, уверяю, Вы преувеличиваете мои скромные заслуги.
На Node.js?
> На Node.js?...на BUS1 на eBPF...
ну да, зачем обращать внимание на комментарии - они за вас уже все решили, и премию от отдела глубокого зондирования rhibm уже получили.Сделаем как в винде, только всем хуж...ой, простите, только гораздо лучше, мы ж куда умнее и продвинутее! Вот например какие классные эксплойты...правда, в винде уже тоже было, году так в 98м, но мы обещаем догнать и перегнать!
Жаль что даром оно нам не надо, потому что винда у нас - уже есть. (ах, ну да, ну да - т-м и жадным опенотсосерам конечно же надо именно даром, и они любое с лопаты схавают не обращая внимания на запах, но зарплату горе-разработчикам с единственной извилиной "как в винде" платят не они)
Яда в комментарии много, а смысл, как мне кажется именно тот же, какой я вложил в первый комментарий.
И да, линуксу не достаёт функций которые были еще в NT4, со стороны базовой системы инфраструктура отсталая.
линуксу НЕ НУЖНЫ "функции которые были в NT4" - те, кому они нужны, могут распаковать архив с nt4 и наслаждаться, если что-то кроме жадности помешало вам это сделать в 1997м году, раз они вам были нужны. Мне вот они были не нужны, поэтому у меня был - линукс, а не NT4.А вот сегодня тем кому нужна нормальная юникс-стайл система без "как в NT4" - бежать уже вообще некуда.
Как это некуда бежать? Есть отличная FreeBSD, куда тащат не корпоративную отрыжку, а годноту вроде ZFS или sendfile async io
https://www.opennet.me/opennews/art.shtml?num=43646
ZFS - это не корпоративная отрыжка? С чего бы?
FreeBSD давно уже стремится стать линуксом (который стремится стать виндой). Ничего интересного.
Только OpenBSD.
> В состав FreeBSD принята высокопроизводительная реализация sendfile от Netflix
> Netflix
> куда тащат не корпоративную отрыжкумда.
> Как это некуда бежать? Есть отличная FreeBSD, куда тащат не корпоративную отрыжку,как это не тащат? Вам же только что показали кино про страдания молодого Оно что в freebsd нет системды?! Просто пока никто из корпораций не пожелал за это платить.
> а годноту вроде ZFS или sendfile async io
годнотой вроде zfs занимаются ажно целых ТРИ хохло"разработчика", не желающие чинить в ней даже легкоустраняемые проблемы, не говоря уже о глобальных - "fsck нет и не предвидится, scrub циклично перезагружает систему", на которые у них и пороха не хватит. В основном копипастящие из, внезапно, zfs on linux - причем с неодолимым отставанием на пять лет даже там, где изменения кажутся полезными, а не явно вредными.
netflix три года пилил асинхонный сендфайл, кстати, совершенно бесполезный с zfs и решающий собственные проблемы нетфликса прежде всего, прежде чем уговорил принять его в апстрим.ну и самое главное - freebsd без портов не умеет примерно ничего полезного. А порты - это внешний по отношению к ней софт, который чем дальше, тем больше будет мигрировать в сторону "нового стандарта". Кто в здравом уме будет сегодня заниматься разработкой под юникс-вообще, а не под этот самый новый стандарт?
> А вот сегодня тем кому нужна нормальная юникс-стайл система
> без "как в NT4" - бежать уже вообще некуда.А вот кстати, ми-минор-коробку не видали?
Оно, конечно, в первую очередь под эмбедщину -- зато наше и нежирное.
>> А вот сегодня тем кому нужна нормальная юникс-стайл система
>> без "как в NT4" - бежать уже вообще некуда.
> А вот кстати, ми-минор-коробку не видали?
> http://emboxing.ru/
> Оно, конечно, в первую очередь под эмбедщину -- зато наше и нежирное.И под GPLv3+ ! Точно, Наше Всё. Дайте два.
...а не, 2-clause permissive и универ-копирайт. Ладно. "Как в НТ4" на подходе, да-да, конечно.
> И под GPLv3+ ! Точно, Наше Всё. Дайте два.Так авторам можно написать -- ну отгрузят под v3+.
> Так авторам можно написать -- ну отгрузят под v3+.Мне-то не надо. И не отгрузят -- зечем им лишние _обязательства_ и проблемы.
OpenBSD
> линуксу НЕ НУЖНЫ "функции которые были в NT4"
> те, кому они нужны, могут распаковать архив с nt4 и наслаждатьсяВообще-то "как в NT4" мало кто из знатоков buzzwords представляет, так как документировано оно не для всех. И уж точно предлагавший удивится, узнав, что какая-нибудь CreateMailslotA() появилась позже и в тамошнем аналоге WinE.
А что за функции в нт4?
иди уже нафиг со своей виндой. достал.
Не нравится винда - смотри на макось. Макось - настоящий UNIX, но без launchd в нём тоже не обошлись.
> Макось - настоящий UNIXНе настоящий, а сертифицированный -- разницу понимать надо.
на фиг не нужно в pid 1 заниматься абсолютным большинством того, что туда в systemd напихали. Тогда и общаться с ним по d-bus не понадобится.
> никто из разработчиков не обращает внимания на такие комментарии. Потому что это предложение НЕ делать чего-нибудь и отказаться от изначальной задачи. Комментарий не предлагает как решить.
> на фиг не нужно в pid 1 заниматься абсолютным большинством того, что
> туда в systemd напихали. Тогда и общаться с ним по d-bus
> не понадобится.Ах, коллега, опять Вы со своим "не нужно".
Аудитория ж верит (вкерует?!), что вот-вот уже-уже почти-почти должны всенепрпеменно подвезти....
...всеобщее процветание и проблагоухание.
Сейчас, только дискетку отформати... ой, не то! только дырочки подлатают, прогрессифных фич накидают -- и прямо сразу так и займутся построением Светлого Настоящего. Сейчас-сенйчас, да.
</таймшер недорого без смс>
Есть 2 демона. Один демон предпримет действия если потребление ресурсов машины такое-то такое-то (придумайте метрику) о чём оповестит второго демона.Проблематика задачи как раз инфраструктурная. Для того чтобы её решить нужно каждый для каждого проекта изобретать велосипед с решением, потому что сам по себе линукс как ОС ни мониторить себя нормально не умеет, ни стандартизированного апи для обмена данными о производительности не имеет, я уже не говорю про RPC на системном уровне.
IPC и RPC в linux, по-моему, не меньше, чем в Windows. И уже довольно давно. Начиная с разных там SUN-RPC.
Да их много и ни одного рабочего стандартизированного варианта.
> Да их много и ни одного рабочего стандартизированного варианта.в смысле? Что Вы понимаете под стандартизироваными? Тот-же SUN-RPC вполне себе есть практически везде - на нём основан NFS (и была реализация в Windows в Windows Services for Unix). А по поводу IPC - тех-же самых BSD-сокетов - так они даже в Windows такие-же, с поправкой на необходимую инициализацию, функцию closesocket()/ioctlsocket() и WSAGetLastError(). Прочих IPC тоже хватает - начиная с обычных FIFO и PIPE-ов, продолжая стандартными posix-овскими семафорами, очередями сообщений, мутексами, разделяемыми областями памяти. Которые более-менее одинаковые во всех UNIX-системах, как в BSD, LINUX и даже в разных там QNX. Кроме того есть ещё и классические unix-ipc, которые тоже до сих пор вполне себе работают и тоже много где поддерживаются.
>> Да их много и ни одного рабочего стандартизированного варианта.
> в смысле? Что Вы понимаете под стандартизироваными?Шоб Керниган и друг его IETF в книжку про Си вписали. Рядом с hello-миром.
>Тот-же SUN-RPC вполне себе есть
> практически везде
>>> Да их много и ни одного рабочего стандартизированного варианта.
>> в смысле? Что Вы понимаете под стандартизироваными?
> Шоб Керниган и друг его IETF в книжку про Си вписали.
> Рядом с hello-миром.К большому сожалению, друг Кернигана уже никуда ничего не впишет..
> То и понимаю, чтобы был стандарт IPC/RPC для работы в операционной системе
> с её компонентами доступный вне мира системных программистов.Прошу прощения, не совсем понял Вашу мысль.. Те-же PIPE-ы и FIFO вполне себе доступны совсем не программистам..
ls -l | grep my_favorite_fileЧерез FIFO вообще можно организовывать взаимодействие неродственных процессов. На уровне:
client$ echo hello > /tmp/server
server$ while true; do REZ=`cat /tmp/server`; echo $REZ; doneЕдинственное ограничение - нет контроля от кого идут запросы и по-моему неделимые сообщения не более 4K.
А то, что сейчас не только пользователи, но и программисты не знают инструментария, и даже не хотят знать, то это да, печальная реальность.
> Вы же понимаете, что не все разработчики ПО одинаково умны и образованы.
> Не все способны пользоваться столь низкоуровневыми стандартами как POSIX. Принять на
> работу человека который сможет забабахать сервис с двумя вышеуказанными демонами для
> предприятия проще и дешевле, когда не требуется такого высокого уровня подготовки.там ничего сложного нет. совсем. аналогичные "какие-то функции, которые надо вызвать что-бы получить какой-то результат".
> у венды IPC/RPC это легаси и история.И что там теперь вместо APC и completion routines? Может и DISPATCH_LEVEL стал историей?
> чтобы добиться паритета в функциях с той же вендойНафейхоа? «Паритет» это вообще что в данном контексте? Встроенную спайварь тоже будем добавлять?
Да, причём уже. https://www.bleepingcomputer.com/news/linux/ubuntu-reveals-d.../
> И тут примечательно, почему никто из разработчиков не обращает внимания на такие комментарии.Давай будем честны - не только на такие. Увы, это лишь характеризует их как высокомерных зазнаек.
> Потому что это предложение НЕ делать чего-нибудь и отказаться от изначальной задачи.
Да. Как будто что-то плохое. Если близкий мне человек, попадёт в секту, например, я постараюсь отговорить его, отказаться от его задачи. Не все начинания благи. Про кривизну архитектуры системды высказывались с момента его появления, и новость вроде текущей - результат в том числе того, что разработчики systemd слишком мало обращают внимание на подобную критику.
> Комментарий не предлагает как решить.
Вообще-то предлагает.
может это не проблема systemd, а проблема о.с.?
может проще написать о.с. systemd-system?
так уже, systemd/Linux называется."ваш новый стандарт".
systemd-system не звучит; то ли дело - потерингукс
>thread 'main' has overflowed its stack
>fatal runtime error: stack overflow
>AbortedТак было бы если бы systemd был написан на Rust.
Леню бы задолбали варнинги с ошибками и он написал бы свой, принципиально новый конпелятор раста :)
systemd-rust?
systemd-rust-runtime-sdk
> Так было бы если бы systemd был написан на Rust.как запилите хотя бы версию 1 (не 0.0.1, учитесь у Лёни) - с меня донейт.
А смысл? Паника будет так и так.
> А смысл? Паника будет так и так.зато квадратноколесность велосипеда будет видна без оптических приборов.
> ядро не может вызвать данный обработчик сигнала и просто завершает процесс с PID 1Ещё и в ядре ошибка.
это не ошибка, это системная функция, точнее, ее отсутствие - ядро писал ретроград Линус двадцать пять лет назад, когда процесс с pid1 к "unmapped памяти" не обращался, поскольку вообще занимался исключительно своим делом - запуском демонов и сбором мусора.
...а потом еще спрашивают, почему разработчики systemd вечно норовят залезть в ядро. Ясно-понятно почему, устаревшая забагованная ерунда с кучей никому не нужных древних ФС (федора их уже выпилила), археологических драйверов, которые сто лет никто не собирает и дальше по тексту. Надо приводить в порядок эту помойку под нужды современного бизнеса.
> ...а потом еще спрашивают, почему разработчики systemd вечно норовят
>Надо приводить в порядок эту
> помойку под нужды современного бизнеса." Можете форкать! "
Денег у вас завались, времени девать некуда. Вперёд[I]!
>>Надо приводить в порядок эту
>> помойку под нужды современного бизнеса.ну в общем-то давно уже за это взялись
> " Можете форкать! "дык им-то зачем - когда они контролируют основной процесс.
Форкать могут те, у кого ни денег, ни возможностей для этого - но у них, обычно, и времени свободного тоже нет. А его, глядя на печальный опыт девуана, надо овердофига даже на мелкий незначительный шаг в сторону.так что в ведре будет то, что нальют корпорации - ну вот для начала прекрасный новый модный нечеловекоуправляемый файрвол (корпорастам не надо, человекоуправляемый у них на входе периметра), а там глядишь и до kdbus дойдет.
Ты что? как это выкинуть устаревшие драйверы ?? а как же сканеры, которые подключаются по LPT и сканируют со скоростью 1 лист за 4 часа ??? - много у кого из линуксоидов такие есть, и пусть там пара вертикальных полос идет и цвето-передача страдает, так РАБОТАЕТ ЖЕ!!! и новый покупать не нужно!! Просто после сканирования еще 4 часа на правку в гимпе потратить и все норм будет!
ты думаешь, мой ls4000 (ни разу не lpt, а очень даже красивый, хотя и мертвый, firewire) в линуксе вообще как-то будет работать?И новый купить, что характерно - не получится.
понятное дело, я для него держу XP на отдельном диске, вместе с устаревшими драйверами и устаревшим всем, чего уже не скачаешь в этих ваших интернетах.
А вот ты, найдя дедушкину фотопленку предвоенных лет - уже не сможешь ее отсканировать с хорошим качеством - _нигде_. Во всяком случае, еще лет через десять, когда умрут пассики и диоды в моем сканере и его братьях - точно.Ни задаром, ни за деньги, ни даже за бесконечно большие деньги.
> ты думаешь, мой ls4000 (ни разу не lpt, а очень даже красивый,
> хотя и мертвый, firewire) в линуксе вообще как-то будет работать?Очень рекомендую VueScan, проверено на Nikon Coolscan 5000 тоже с IEEE1394.
Автор, кстати, немного по-русски понимает :-)
> это не ошибка, это системная функция, точнее, ее отсутствие - ядро писал
> ретроград Линус двадцать пять лет назад, когда процесс с pid1 к
> "unmapped памяти" не обращалсяДа не в этом там дело. Там alloca
Я про обработчик SIGSEGV, который ядро судя по новости то вызывает, то нет.
Вот сейчас мы и узнаем, что из себя представляют разработчики systemd на самом деле. Если к 242 они выпилят из кодовой базы все выделяемые на стеке массивы переменной длины, то не всё ещё потеряно.
не являясь хейтером systemd, часто задаюсь вопросом, зачем это абсолютно сырое, необкатанное и забагованное поделие пропихивают с таким скрипом в дефолт? ну валялось бы, где-нибудь в репах и вызревало. смотрю на работу мантейнеров дебиан, как они с ним откровенно говоря я***буца... ну не в какие рамки же
вы там вот выше прочитайте детскую радость очередного любителя "как в винде", сразу и поймете.А что, по вашему, разработчики дистрибутивов какие-то другие, им не хочется того же самого?
Вот ты так говоришь "как в винде", будто в этом есть что-то плохое...
А ведь меинтейнеры некоторых дистрибутивов на него перешли не просто так, что-то же им там понравилось.
Видимо, было предложение, от которого они не смогли отказаться?
>Вот ты так говоришь "как в винде", будто в этом есть что-то плохое...Нет ничего в этом плохого, за исключением того, что в В-нде это есть уже давно и без всяких каков. Соответственно кому это было надо (или хотя бы просто устраивало) - давно уже на ней. А другие ОСи ценились именно за то, что они другие, что там не "как в В-нде". А зачэм нам два Сынавских?
> не являясь хейтером systemd, часто задаюсь вопросом, зачемНу, и чего надумал, не томи?
" Не даёт ответа. "(ц)Гоголь ?
продолжаю наблюдения, почитывая openbsd юзер гайд
Не ошибается только тот, кто ничего не делает.
Нет ни одного серьёзного программного продукта, в котором бы отсутствовали баги.
И чем более распространён и полезен продукт, тем чаще в нём будут выявлять уязвимости.Не хочешь видеть плохих новостей про свою любимую программу, тогда будь изгоем и выбирай то, что никому кроме тебя не нужно.
>[оверквотинг удален]
> в systemd, её можно будет удалять из ядра, пока наконец ядро
> не станет микроядерным.
> Проблема 1 в том, что сейчас в ядре нет необходимого функционала для
> нормального функционирования внешних сервисов, а разработчики systemd не могут сразу сказать
> какой функционал им ещё понадобится, добавляя его по мере необходимости.
> Проблема 2 в том, что разработчики ядра не хотят удалять перенесённую в
> systemd функциональность из ядра и отказываются принимать патчи, которые приведут к
> необходимости удаления из ядра части функционала в будущем. К счастью, прогресс
> наступаем им на пятки, а сложность реализации нового функционала превышает их
> возможности, вынуждая переносить функциональность в systemd.э.. прошу прощения, но у Вас, с таким подходом будет микроядерная ОС с монолитным systemd. Имхо, конечно, это гораздо хуже, чем монолитная ОС с текущим ядром. К сожалению, золотой век с монолитной ОС и обычным sysvinit уже миновал...
> Сейчас всё прогрессивное человечество ждёт смерти отца-основателя, который и в 25 лет,
> и сейчас считает "своё" монолитное ядро лучшим творением человечества и категорически
> противится любым изменениям.надеюсь, что раньше в страну вечной охоты отправится автор systemd.
> systemd не монолитный и состоит из набора несвязанных между собой сервисов, каждый
> из которых можно заменить на аналог или вообще удалить. Но обычно
> - да, будет использоваться весь набор библиотек одного поставщика.Которые непонятно зачем написаны, ведь есть аналоги, которые были ещё задолго до systemd. И которые уже, по большому счёту, отлажены.
> В состав systemd не входят драйверы.
Зато входят DHCP-, DNS-сервера, генератор QR-кодов и прочие незаменимые в домашнем хозяйстве вещи.
>> Которые непонятно зачем написаны, ведь есть аналоги, которые были ещё задолго до systemd.
> Вы либо крайне саркастичны в своём комментарии либо... пфффф... вы серьёзно не
> знаете зачем они там написаны? За тем, чтобы стандартизировать реализацию определённой
> функции внутри базовой системы.Боюсь, кроме vendor-lock (c)(tm) ничего на ум не приходит.
> Например: Система логгирования в системе ЕСТЬ. У неё апи такое-то. Если пользователь
> заменил систему логирования на альтернативную, то она всё равно ЕСТЬ и
> апи сохраняется. Теперь логгирование в этом примере замените на DHCP-клиент, кэширующие
> DNS-резолвер и так далее и тому подобное.И до этого система логирования, ака syslog имела стандартизированный интерфейс. И система DNS, если вы про прикладной доступ.
> systemd не монолитный и состоит из набора несвязанных между собой сервисов,
> каждый из которых можно заменить на аналог или вообще удалить.Это очередной постулат или проверяли на себе?
> systemd не монолитный и состоит из набора несвязанных между собой сервисов, каждый из которых можно заменить на аналог или вообще удалить.И на что можно заменить systemd-logind? А systemd-networkd? А mdev/eudev вместо systemd-udev будет работать?
Да ну? Даже udev можно открутить?
> микроядерная ОС с монолитным systemdой это вряд ли, речь идёт просто о грибридном подходе, когда часть ядра в нулевом кольце, и куча всего в юзерспейсе. Там и подходы разные, вон есть Darwin, BSD, Windows NT и куча других ОС, которые используют этот подход.
Да. Linux скоро превратится в BSD со своим оригинальным ядром. И я не вижу, чтобы Линус был против.
>> микроядерная ОС с монолитным systemd
> ой это вряд ли, речь идёт просто о грибридном подходе, когда часть
> ядра в нулевом кольце, и куча всего в юзерспейсе. Там и
> подходы разные, вон есть Darwin, BSD, Windows NT и куча других
> ОС, которые используют этот подход.это-то понятно, просто продолжил мысль, изложенную в "проблеме 2" в исходном посте Анонима, ну и немного утрировал. Просто у него так получалось, что надо выкидывать функционал из ядра и впихивать в systemd. Хотя.. наверное я таки, наверное, за. Надеюсь, что при таком подходе systemd рухнет под своим весом гораздо раньше.. Вполне вероятно похоронив всех, кто окажется в непосредственной близости. Может даже и всех нас.
>К сожалению, золотой век с монолитной ОС и
> обычным sysvinit уже миновал..." Немое кино уже кончилось, а звуковое ещё не началось. "
Так вот и мучаемся с сабжом, ага. ><<<W>
Наконец-то островок адекватности на опеннете.
> микроядро + сервисы (systemd)Я согласен, что это логичный способ развития, но тут смотря что называть микроядром, вон у макоси и венды тоже "полунедомикроядра", то есть никакие не микроядра, на самом деле. Настоящее микроядро выдаёт крайне низкую производительность на ПК (в смысле машины фон Неймана) на некоторых тестах и исследования закончились как раз на миниксе или очередном меке, не помню... Вообще этот спор монолитности и микроядерности так и не завершился, но бизнес выбрал нечто среднее между ними и мне не известно, чтобы кто-то продолжал финансирования экспериментов.
Те проблемы которые вы там пишете, никакие не проблемы вовсе. Это вопрос времени:
1. Нельзя реализовать в ядре апи для функционала, который незадокументирован. Без ТЗ результат ХЗ.
2. Нельзя ломать юзерспейс. Легаси и поддержка софта ставится и будет ставиться во главу угла при любом лидере.
Ни Линус, никто другой не допустит, чтобы из-за удаления подсистемы куча софта отвалилась и нужно было бы всё переписывать.
Насчёт прогрессивности этого человечества я вот что спрошу, какие конкретно изменения эдакий тиран Линус отказался принять в ядро по монолитным причинам? Ссылочку на мейллисты в студию.
Линуса, Столмана и идеологию в одно предложение ставить - фактическая ошибка. Послушайте хотя бы Q&A Sessions с Линусом и послушайте, что он думает про FSF, их идеологию и GPLv3.
Юзерспейс - это ring 3, ничего тут вольного нет.
Нвидия. Ну хотя бы эти источники дай, я поизучаю. Просто если компания:
1) Отказывается предоставлять поддержку своему покупателю по оптимусу
2) Выдаёт лицензионные проблемы своих патчей за технические проблемы
То это не проблема Линуса, это проблема нвидии, которую она должна сама решить.
> Вообще этот спор монолитности и микроядерности так и не завершился, но
> бизнес выбрал нечто среднее между ними и мне не известно, чтобы
> кто-то продолжал финансирования экспериментов.ну есть L4 например. Кому надо попиливают
> Затем, что реализовать на базе монолитной ОС (коей сейчас является Линукс) современную
> функциональность становится сПрогресс не остановить. s-d-mikrocerneld в каждый дом, шагает по планете. Будет только хуже. Вступайте в Автодор! </>
> Прогресс не остановить. s-d-mikrocerneld в каждый дом, шагает по планете.может, кто-то еще успеет с планеты куда-нибудь свалить?
в эпидемию чумы, к сожалению, верится слабо, омнирезистентный триппер пока что-то заглох, эбола это только для негров... других средств к резкому оздоровлению человечества что-то не видно.
> s-d-mikrocerneldТаки ви пrедлагаете запилить поддержку GNU/Hurd?
>> s-d-mikrocerneld
> Таки ви пrедлагаете запилить поддержку GNU/Hurd?Нет. Зюстемдешнутым это не подойдёт:
+ В нём слишком много bash. + В нём недостаточно LGPL. + Опознавание своих по прыщам и веснушкам не проходит.
>микроядро + сервисы (systemd)Hurd, Genode обходятся микроядро + сервисы. Systemd им как собаке пятая нога.
>Не ошибается только тот, кто ничего не делаетэта фраза не для всех случаев подходит, ошибка ошибке рознь. Или вы пиццу передержали в духовке и она подгорела, или вы врач и совершив ошибку убили пациента.
За такие ошибки, как эта нужно брить налысо тупыми ржавыми ножами, поливая голову подсоленой водой. Причем публично на площади. А потом, приковав к столбу разрешить каждому желающему пнуть виновных под срандель.
Потому что портянки ещё более сырых, забагованных и вообще недоделанных инит-скриптов достали всех.
Никто не запрещает использовать протестированные, без ошибок и полностью доделанные инит скрипты.
Ну да, а еще можно просто отожрать под непривилегированным юзером nГб рамы, и система все так же умрет. Иными словами, сценария применения у уязвимости нет пока не доказана возможность выполнить код от рута.
При init-е такого не было!!!
> позволяющая вызвать крах управляющего процесса инициализации (PID1) через отправку непривилегированным
> пользователем специально оформленного сообщения через шину D-Bus.Никогда ж такого ж не было!
Ой, было
https://www.opennet.me/opennews/art.shtml?num=45244
> 29.09.2016 19:49 Локальная DoS-уязвимость в systemd
> В системном менеджере systemd выявлена локальная уязвимость. Процесс PID 1 зависает на системном вызове pause() при поступлении в сокет уведомлений systemd
>[...] любые локальные пользователи могут вызвать отказ в обслуживании на системах с systemd.
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done
но давно и поэтому почти неправда! :)
>сборка в GCC c включением опции "-fstack-clash-protection"А куда вы некрофилов дели? На этом месте должна была выскочить парочка с воплем, что на их куркуляторах это будет тормозить.
>>сборка в GCC c включением опции "-fstack-clash-protection"
> А куда вы некрофилов дели? На этом месте должна была выскочить парочка
> с воплем, что на их куркуляторах это будет тормозить.Все перековались уже. Вкушають прогресс, только за ушами трещит.
в systemd найдена уязвимость - инородное тело в виде ядра linux
>В systemd найдена уязвимостьТо ли ещё будет... Более кривого кода чем у сабжа вряд ли можно ещё где-то найти.
Баш Портянщик пишет:Бро!
>>В systemd найдена уязвимость
> То ли ещё будет... Более кривого кода чем у сабжа вряд ли
> можно ещё где-то найти.Да. Только кривой код сам по себе не причина. Причина в отсуствии архитектуры, шапкозакидательстве (pat intended tnx) апстрима и "неискренненьких" целях проекта. Код хоть обисправляйся -- причины-то не изменятся.
Отсутствие архитектури и кривой код - это про sysvinit & bsd init. Натащить кучу баш-скриптов, которые в каждом дистрибутиве работают по-своему, а потом ждать при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибками.
Единственный плюс этого подхода - можно даже не пытаться реализовывать надежно работающий hotplug.
Вы же в курсе что полная поддержка plug and play появилась в GNU/Linux раньше чем в Windows, для примера.
> bsd init.
> Натащить кучу баш-скриптов,
> bsd
> баш/0
> Отсутствие архитектури и кривой код - это про sysvinit & bsd init
Типа, слишком мало кода для серьезной системы инициализации, нужно хотя бы 400 000 строк?
% cloc /usr/src/sbin/init
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 1 253 349 1457
make 1 5 3 24
C/C++ Header 1 2 36 7
-------------------------------------------------------------------------------
SUM: 3 260 388 1488
Или слишком понятный код, без кучи однобуквенных переменных и захардкоженых констант?
if (sp->se_type) {
/* Don't use malloc after fork */
strcpy(term, "TERM=");
strlcat(term, sp->se_type, sizeof(term));
env[0] = term;
env[1] = NULL;
}
а нужно былоhttps://github.com/systemd/systemd/blob/ad16158c10dfc3258831...
ret = new(char, (e - slice) + 1 + strlen(name) + 6 + 1);
---
strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e);
--
Они не понимают о чём говорят и не разбираются, просто повторяют что им потеринг сказал, фанатики.
> фанатикиГорше всего, что не просто фанатики, а ещё и не лечатся...
PS: в смысле картина маслом:
- а ваши башпортянки!!!1 а наша системдешечка!!111
- внутрь смотрел?
- у вас никаких аргументов!
- вот сюда конкретно смотрел? с секундомером стоял?
- ну вот, опять эти неосиляторы со своими абстрактными доводами!
- *занавес*
> при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибкамиМожете назвать дистр, в котором sysvinit при каждой загрузке сыпался с нечитаемыми ошибками? И что Вы определяете как "нечитаемость"?
>а потом ждать при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибками.Вы или троль или неуч. Когда я пользовался арчем с его bsd-like-init никаких 5 минут не было, на простом hdd-sata2 загрузка может минуту занимала, причем это от груба до полной готовности десктопа. Даже тогда в /etc/rc.conf была возможность указать запускать демон в бекграунд, или запретит загрузку или указать порядок загрузки демонов. Все в одном файле, а не в непойми-каких-каталогах-которые-я-забуду-где-находятся.
Если ошибки были - они были вполне читаемы, потому, что не было никаких заставок, а где заставки были, их можно было отключить и почитать как проходит загрузка. Тогда все было лучше, но вы же не поверите, сейчас xfce4 на ssd загружается дольше, чем xfce4 в 2008 году на sata2-hdd.
Нет не знаете, ничто не мешает вам поставить тот дистрибутив и убедиться.
# systemd-analyze
Startup finished in 3.528s (kernel) + 42.502s (userspace) = 46.031s
И как это опровергает быструю загрузку на sysvinit?
Это опровергает фантазии о медленной загрузке в systemd.
Вообще то нет
root@ThinkPad-R51:~# systemd-analyze
Startup finished in 8.617s (kernel) + 46.529s (userspace) = 55.146s
graphical.target reached after 46.491s in userspace
root@ThinkPad-R51:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.70GHz
stepping : 6
microcode : 0x18
cpu MHz : 1700.000
cache size : 2048 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe bts cpuid est tm2
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
bogomips : 3397.32
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 32 bits virtual
power management:root@ThinkPad-R51:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
root@ThinkPad-R51:~#
> root@ThinkPad-R51:~# systemd-analyze
> Startup finished in 8.617s (kernel) + 46.529s (userspace) = 55.146s
> graphical.target reached after 46.491s in userspaceКруто! Правда, у мня примерно столько же (меньше минуты) когда-то "изкоробочный бсдинит" с убогого 1.8" харда грузился.
> root@ThinkPad-R51:~# cat /proc/cpuinfo
> 100500 ненужных деталей, вместо пары характеристик загрузочного диска
> root@ThinkPad-R51:~#
root@ThinkPad-R51:~# hdparm -I /dev/sda/dev/sda:
ATA device, with non-removable media
Model Number: FUJITSU MHT2060AT
Serial Number: NN4HT5214GVC
Firmware Revision: 8423
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 3a
Supported: 6 5 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 117210240
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 57231 MBytes
device size with M = 1000*1000: 60011 MBytes (60 GB)
cache/buffer size = 8192 KBytes (type=DualPortCache)
Capabilities:
LBA, IORDY(cannot be disabled)
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128
Recommended acoustic management value: 254, current value: 128
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
> Это опровергает фантазии о медленной загрузке в systemd.А вот была статья о том, как ребята задались загрузить eeePC (это ещё _совсем_ дохлый атом) за пять секунд. Да, с его чахлым SSD. Нет, никакими systemd не воняло ещё, хотя ещё вменяемый Леннарт уже дотянулся до udev.
https://lwn.net/Articles/299483/
Говорю же, чадо -- марш учить матчасть. В жизни таким невменяемым быть очень сложно, она-то сразу в лоб учит.
Вот EeePC c Xubuntu 18.04. И это время загрузки в графическое окружение, а не в командную строку.root@EeePC-901:~# systemd-analyze
Startup finished in 5.463s (kernel) + 21.878s (userspace) = 27.341s
graphical.target reached after 21.831s in userspaceroot@EeePC-901:~# hdparm -I /dev/sda
/dev/sda:
CompactFlash ATA device
Model Number: ASUS-PHISON SSD
Serial Number: SOQ1782276
Firmware Revision: TST2.04U
...
root@EeePC-901:~# hdparm -I /dev/sdb/dev/sdb:
CompactFlash ATA device
Model Number: ASUS-PHISON SSD
Serial Number: SOQ2780070
Firmware Revision: TST2.04P
...root@EeePC-901:~# dmidecode -t2
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: 901
...
> The superfast (and furious) systemD
> Startup finished in 5.463s (kernel) + 21.878s (userspace) = 27.341shttps://lwn.net/Articles/299483/
> 2008
> At the Linux Plumbers Conference Thursday, Arjan van de Ven, Linux developer at Intel and author of PowerTOP, and Auke Kok, another Linux developer at Intel's Open Source Technology Center, demonstrated a Linux system booting in five seconds. The hardware was an Asus EEE PC, which has solid-state storage, and the two developers beat the five second mark with two software loads: one modified Fedora and one modified Moblin
> booting in five seconds
> 21.878s (userspace)Эпичненько ))
Эпичненько что Ubuntu из 2019-го года с дьявольским systemd грузится 27 секунд, а Fedora из 2008-го c божественным System V Init — 45 секунд на одинаковом железе.
> Эпичненько что Ubuntu из 2019-го года с дьявольским systemd грузится 27 секунд,Эпичненько, что читать сестемдатнутные умеют очень уж выборочно.
> а Fedora из 2008-го c божественным System V Init — 45 секунд на одинаковом железе.«It spends 12 seconds running modprobe running a shell running modprobe, which ends up loading a single module»
Ну и ловко проигнорированное
> booting in five seconds
> «It spends 12 seconds running modprobe running a shell running modprobe, which
> ends up loading a single module»Ты ещё не понял, что это и есть вся суть sysvinit/bsdinit/openrc с костылями вроде rc и прочими парсерами скриптопортянок?
>> Ну и ловко проигнорированное
> booting in five seconds
> Ты ещё не понял, что это и есть вся суть sysvinit/bsdinit/openrc
> с костылями вроде rc и прочими парсерами скриптопортянок?О-оо, кто-то напарывается на ответ Линуса насчёт "кому грузить модули". Причём так и не оценив иронии момента.
Почти уверен, что любой нормальный дистрибутив 2008 года (федора к ним ни разу не относилась) и результат в таком "тесте" покажет лучше. Можно попробовать с альтом -- правда, у меня нынче под рукой вообще одни эльбрусы, для них эти ваши убунтофедоры бывают разве что в бинарной трансляции.
>> ends up loading a single module»
> Ты ещё не понял, что это и есть вся суть sysvinit/bsdinit/openrc с
> костылями вроде rc и прочими парсерами скриптопортянок?Притягивание за уши, лвл 80?
>>> Ну и ловко проигнорированное
>> booting in five seconds
> Лови: https://www.youtube.com/watch?v=M6e-ANgye30И? 8 минут любоваться на поттеринга желания нет.
Или это был намек на
> 2013, 5s Boot DeliveredТак то похоже было из разряда "обещать - не значит жениться", иначе тут бы не хвастались
> # systemd-analyze
> Startup finished in 3.528s (kernel) + 42.502s (userspace) = 46.031s
> root@ThinkPad-R51:~# systemd-analyze
> Startup finished in 8.617s (kernel) + 46.529s (userspace) = 55.146sКстати, о скорости загрузки в более современных (2017) условиях и реалиях, ловите:
www.youtube.com/watch?v=hx30Z7_G-vk
Естественно, НеСистемД с треском проиграл, заняв предпоследнее место! ))
Кстати, я не выключал никакие сервисы:root@EeePC-901:~# systemctl list-unit-files | grep enabled
acpid.path enabled
apport-autoreport.path enabled
cups.path enabled
accounts-daemon.service enabled
anacron.service enabled
apparmor.service enabled
autovt@.service enabled
avahi-daemon.service enabled
bluetooth.service enabled
console-setup.service enabled
cron.service enabled
cups-browsed.service enabled
cups.service enabled
dbus-fi.w1.wpa_supplicant1.service enabled
dbus-org.bluez.service enabled
dbus-org.freedesktop.Avahi.service enabled
dbus-org.freedesktop.ModemManager1.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.resolve1.service enabled
dbus-org.freedesktop.thermald.service enabled
getty@.service enabled
gpu-manager.service enabled
irqbalance.service enabled
kerneloops.service enabled
keyboard-setup.service enabled
lm-sensors.service enabled
ModemManager.service enabled
network-manager.service enabled
networkd-dispatcher.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager-wait-online.service enabled
NetworkManager.service enabled
ondemand.service enabled
pppd-dns.service enabled
rsync.service enabled
rsyslog.service enabled
setvtrgb.service enabled
snapd.autoimport.service enabled
snapd.core-fixup.service enabled
snapd.seeded.service enabled
snapd.service enabled
snapd.system-shutdown.service enabled
spice-vdagent.service enabled
spice-vdagentd.service enabled
syslog.service enabled
systemd-fsck-root.service enabled-runtime
systemd-resolved.service enabled
systemd-timesyncd.service enabled
thermald.service enabled
udisks2.service enabled
ufw.service enabled
unattended-upgrades.service enabled
ureadahead.service enabled
whoopsie.service enabled
wpa_supplicant.service enabled
acpid.socket enabled
apport-forward.socket enabled
avahi-daemon.socket enabled
cups.socket enabled
snapd.socket enabled
uuidd.socket enabled
remote-fs.target enabled
anacron.timer enabled
apt-daily-upgrade.timer enabled
apt-daily.timer enabled
fstrim.timer enabled
motd-news.timer enabled
snapd.snap-repair.timer enabledИ большую часть времени загрузки занимает подключение к Wi-Fi сети:
root@EeePC-901:~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.graphical.target @22.118s
└─multi-user.target @22.118s
└─virtualbox.service @21.520s +591ms
└─network-online.target @21.491s
└─NetworkManager-wait-online.service @14.879s +6.610s
└─NetworkManager.service @12.258s +2.573s
└─dbus.service @11.739s
└─basic.target @11.438s
└─sockets.target @11.438s
└─snapd.socket @11.409s +25ms
└─sysinit.target @11.395s
└─systemd-timesyncd.service @11.007s +386ms
└─systemd-tmpfiles-setup.service @10.819s +162ms
└─systemd-journal-flush.service @6.550s +4.168s
└─var.mount @6.403s +93ms
└─systemd-fsck@dev-disk-by\x2duuid-659ad04f\x2d2531\x2d404b\x2d87e5\x2dfc9fd5db454a.service @6.068s +217ms
└─dev-disk-by\x2duuid-659ad04f\x2d2531\x2d404b\x2d87e5\x2dfc9fd5db454a.device @6.062s
> Кстати, я не выключал никакие сервисы:Отгововрки, честно сказать, никому не интересны.
> И большую часть времени загрузки занимает подключение к Wi-Fi сети:О-отличная демонастрация качества распараллеливания загрузки! Благодарю.
>> Кстати, я не выключал никакие сервисы:
> Отгововрки, честно сказать, никому не интересны.
>> И большую часть времени загрузки занимает подключение к Wi-Fi сети:
> О-отличная демонастрация качества распараллеливания загрузки! Благодарю.+1
https://www.anekdot.ru/id/-40121022/ Ачивмент опенед!
> баш-скриптов, которые в каждом дистрибутиве работают по-своемуА почему они должны работать одинаково? То что хорошо для ноута может быть плохим решением для сервера.
Если ты пишешь софтину с демоном (тем более с таким, который зависит от других), тебе придется писать свои init-скрипты под каждый дистрибутив, либо ей никто не сможет пользоваться.
Инит срипты пишут разработчики дистрибутива, под свой дистрибутив сами.
O RLY? И когда же это они их напишут?
А когда пакет будут делать, тогда и напишут, по стандартам своего дистрибутива.
То есть через несколько лет в лучшем случае.
Если нужных зависимостей в дистрибутиве нет то возможно и дольше. Unit файл тут ничем не поможет.
А не надо придумывать, что нужных зависимостей нет.
> А не надо придумывать, что нужных зависимостей нет.Так это автор исходного сообщения написал: «Если ты пишешь софтину с демоном (тем более с таким, который зависит от других)»
С чего он взял что они есть в том дистрибутиве?
Ещё раз для невменяемых: нужные зависимости есть. Это дано. Но с sysvinit/bsdinit жизнь от этого не сильно упрощается.
Аргументы кончились, пошли попытки оскорбления? :-)А откуда взялись эти зависимости? Кто сделал пакет для них для _этого конкретного_ дистрибутива? Кто их поставил на хост?
Если вы думаете что программы устанавливают на сервер через make install используя дефолтные юнит файлы или инит скрипты из исходного кода демона, то вы сильно ошибаетесь.
А unit файлы не надо писать под каждый дистрибутив? У разных дистрибутивов разные зависимости и расположение каталогов например.
Каталоги тут вообще при чём? И да, в systemd всё стандартизовано и мне ещё ни разу не приходилось писать разные unitы (но даже если и пришлось бы - это было бы гораздо легче из-за их декларативной природы и маленького размера).
В каталогах лежат запускаемые файлы и каталоги передаются аргументами и параметрами запускаемым демонам, скрипты тоже маленького размера и стандартной структуры.
Понятно, очередной покусанный bsdinit.
Нечего возразить? :-)
Если нечего возразить то просто промолчи, не обязательно пытаться писать оскорбления :-)
Задание на дом, возьмите unit файл из redhat и попробуйте запустить его в debian, например:
https://git.postgresql.org/gitweb/?p=pgrpms.git;a=blob;f=rpm...подсказка: в debian нет каталога /var/lib/pgsql
И дальше что? Это не "unit файл из redhat", а unit из Postgres ДЛЯ Red Hat. Ключевое слово - из Postgres. То есть сервис пишут разработчики приложения, а уж как - это другой вопрос.
> И дальше что? Это не "unit файл из redhat", а unit из
> Postgres ДЛЯ Red Hat. Ключевое слово - из Postgres. То есть
> сервис пишут разработчики приложения, а уж как - это другой вопрос.Раньше было несколько подходов к инициализации:
- sysv style
- bsd styleя так понимаю, исходя из этого сами разработчики дистрибутива Linux и Unix должны были писать соответствующие сценарии, вплоть до врисовывания вызова какого-нибудь условного /usr/bin/postgres в какой-нибудь /etc/rc.local, т.е. вообще без всяких служб, а чисто - вызов какой-то программки тогда, когда уже всё загрузилось и вроде уже работает (a-la autoexec.bat, если Вы понимаете о чём я). Это сейчас уже кроме Linux-а ничего не осталось, а тогда была жива, Solaris, семейство *BSD, разные там AIX-ы и прочие HPUX-ы с TRU64. Т.е. получается революция Поттеринга стала возможна только потому, что остальные Unix-ы вымерли и на них никто не закладывается (как и он сам). Иначе свои unit-файлы, для своего дистрибутива Red Hat Enterprise Linux бы писал Поттеринг, а в свободное время, если-бы оно оставалось, потихоньку-бы пилил свой systemd, и уже, скорее всего, без QR-кодов и прочих встроенных http-серверов.
Кстати, для FreeBSD, судя по статье (https://postgrespro.ru/docs/postgresql/10/server-start.html), тоже был свой скрипт и тоже от разработчиков Postgres.
> а потом ждать при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибками.Если дистрибутив которым вы пользовались был сделан плохо, то чем вам тут поможет systemd? Авторы плохого дистрибутива и unit файлы напишут плохо, в чём разница?
Дистрибутв тут ни при чем. sysvinit и bsdinit в принципе не умеют в зависимости. В sysvinit они сбоку как костыль, в bsdinit всё просто прибито гвоздями, но это тоже не помогает.
Ну и что?
В docker systemd не нужен, в kubernetes тоже, сервер в стойке никто каждый день не перезагружает, для чего вам это всё, systemd для гуголь ноута?
> sysvinit и bsdinit в принципе не умеют в зависимости. В sysvinit они сбоку как костыль, в bsdinit всё
> просто прибито гвоздями, но это тоже не помогает.О, сколько вам открытий чудных!
% head /etc/rc.d/local_unbound
#!/bin/sh
#
# $FreeBSD$
## PROVIDE: local_unbound
# REQUIRE: FILESYSTEMS defaultroute netwait resolv
# BEFORE: NETWORKING
# KEYWORD: shutdown% rcorder /etc/rc.d/*|grep -B3 local_
/etc/rc.d/netwait
/etc/rc.d/resolv
/etc/rc.d/defaultroute
/etc/rc.d/local_unbound
А теперь фокус (внимание, истово верующим поттеринганцем лучше не читать! Читающим приготовиться к разрыву э шаблона!)
% echo '#!/bin/sh
#
# $FreeBSD$
#
# PROVIDE: local_anon
# REQUIRE: FILESYSTEMS local_unbound' > /tmp/local_anon/etc/rc.d/devd
/etc/rc.d/netwait
/etc/rc.d/defaultroute
/etc/rc.d/local_unbound
/tmp/local_anonman rc
> Operation of rc
> 7. Invoke rcorder(8) to order the files in /etc/rc.d/ that do not have
> a “nostart” KEYWORD (refer to rcorder(8)'s -s flag).
Первую строчку съело при копипасте:>
> % echo '#!/bin/sh
> #
> # $FreeBSD$
> #
> # PROVIDE: local_anon
> # REQUIRE: FILESYSTEMS local_unbound' > /tmp/local_anon% rcorder /etc/rc.d/* local_anon|grep -B 4 local_anon
> /etc/rc.d/devd
> /etc/rc.d/netwait
> /etc/rc.d/defaultroute
> /etc/rc.d/local_unbound
> /tmp/local_anon
>
"Ах, посмотрите на мои костыли! Разве они не прекрасны?"
Костыль к init под названием rc умеет парсить костыльные комментарии в шелл-портянках. Не это ли верх архитектурного изящества?ЗЫ в sysvinit такие костыли тоже любят
> Костыль к init под названием rc умеет парсить костыльные комментарии в шелл-портянках.То ли дело некостыльные, модные и молодежные юниты!
[Unit]
Description=Service B
Requires=a.service
After=a.service
Правда, у меня для вас плохие новости:
У вашего костыля к инит на 400 000 строк кода все то же самое:https://github.com/systemd/systemd/search?q=UnitDependencytype=
только парсинг раскидан еще и по 100500 местам
https://github.com/systemd/systemd/search?l=C&q="Wants=...
наверное, чтобы желающим что-то поправить не сильно скучно было.> Не это ли верх архитектурного изящества?
То ли дело системда -- главное в сам код не заглядывать, а то про «изящество на архитектурном уровне» аж легенды ходят.
>> Не это ли верх архитектурного изящества?
> То ли дело системда -- главное в сам код не заглядывать, а
> то про «изящество на архитектурном уровне» аж легенды ходят.Думаете, допрёт? Мне всё больше кажется, что он невменяем -- именно в том плане, что не воспринимает фактические аргументы, а пытается изо всех сил искать и приводить "удобные".
С вменяемым человеком можно прийти с разных позиций, обсудить, поспорить даже, уйти на разных позициях -- но хоть чем-то обогатиться или по крайней мере проверить свои факты и выводы.
А невменяемый -- пустая трата времени. Причём наверняка что сообщества, что общества, что родителей... :(
> Думаете, допрёт? Мне всё больше кажется, что он невменяем -- именно
> в том плане, что не воспринимает фактические аргументы, а пытается изо
> всех сил искать и приводить "удобные".Так и я довольно вяло потролливаю, причем старыми (частью копипащеными) аргументами, надеясь все же на какой-то новый вариант ответа или даже опровержения. Но увы.
> С вменяемым человеком можно прийти с разных позиций, обсудить, поспорить даже
Диалог с вменяемым человеком вообще редко начинается с довольно категоричных и провокативных утверждений (см #210) ;)
>так как в ходе атаки обращение производится к неотражённым страницам памяти (unmapped), ядро не может вызвать данный обработчик сигналачто за волшебные такие страницы, из-за которых сигнал не вызывается?
я конечно понимаю, что фактчекинг нынче не в моде, но...signal(SIGSEGV, my_handler);приводит к успешному вызову обработчика
*((int*)(0x44444444)) = 0x44444444;
signal(SIGSEGV, (__sighandler_t)0xdeadbeef);
Пример некорректен, дан для простоты наглядности. Хендлеру для работы нужен стек.
> Пример некорректен, дан для простоты наглядности. Хендлеру для работы нужен стек.да, действительно, там же стек переполнен...
...просто в новости оно как-то мутно описано
http://man7.org/linux/man-pages/man2/sigaltstack.2.htmlThe most common usage of an alternate signal stack is to handle the SIGSEGV signal
опять портянки оказались безопаснее и комфортнее... да еще и быстрее компутер загружают...
Прогресс вообще зло. В пещерах и на деревьях было лучше.
Неправда, systemd это не прогресс,с чего вы взяли что любое изменение это всегда прогресс?
Это не я решил, а подавляющее большинство дистрибутивов. Все основные во всяком случае.
> Это не я решил, а подавляющее большинство дистрибутивов. Все основные во всяком
> случае.Он такого не решали.
https://en.wikipedia.org/wiki/Systemd#Adoption
> https://en.wikipedia.org/wiki/Systemd#AdoptionПроцитируйте пожалуйста где там написано что «большинство дистрибутивов решило что systemd это прогресс».
Оно не само решило, его ZOG заставило перейти на systemd?
> Оно не само решило, его ZOG заставило перейти на systemd?Гругря, да -- уж не знаю, что тут будет за Z и O, а G в данном случае -- чётко GNOME3.
Говорю же, марш учить матчасть, школодранцы.
>> https://en.wikipedia.org/wiki/Systemd#Adoption
> Процитируйте пожалуйста где там написано что «большинство дистрибутивов решило что
> systemd это прогресс».Война - это мир, черное - это белое, ад-опшон - это "прогресс", доля "рынка" - это "успех"...
Новояз этих, как их... ну, с мозгом работающим в направлении, кому б продаться.
http://www.opennet.me/openforum/vsluhforumID3/116553.html#57Иного они не разумеют -- аксиоматика не та, самосознание не ... ну, тоже чего-то "не".
Поэтому Главный Аргумент -- просто повторять требуемый вывод.
Н - Настойчивость. У - Уверенность. Р - Руки порежет.
> Прогресс вообще зло. В пещерах и на деревьях было лучше.Прогресс "вообще" -- не доказано, и, типа, не об этом речь.
Не надо кривых обощений и спрыг-спрыгов.
"Прогресс" _в s-d_ - да, зло.
Прололжайте прыгать по расчёске.
Бугага таки нашли, не прошло и трех лет.
На самом деле там еще 14 подобных
NOTABUG! сопсобных уложить и pid 1 и ядро за одно.
Тут в обсуждениях мелькало, что вот systemd пытается сделать в линуксе как в винде, в одном комментарии даже говорится, что, цитата: "линуксу не достаёт функций которые были еще в NT4".Кто-нибудь может объяснить, что за функции такие в винда вообще и нт4 в частности. Мб дилетантский вопрос, но мне не понятно, вроде в линуксе всё для жизни есть, всё примерно то же самое, что и в винде, можно делать. Каких же там функций нет на уровне базовой системы?
> Каких же там функций нет на уровне базовой системы?Божественности! Давно известно, что в Виндовс - иконы и службы, а в Линуксе - демоны и зомби...
В винде зомби тоже есть
> В винде зомби тоже естьНу да, только там они за монитором сидят
Даже не как в винде, а как в макоси и лучше. Функции эти - зависимости между сервисами, запуск сервисов по событиям (например вставили USB-аудиокарту - запустился PulseAudio), параллельный запуск сервисов, контроль состояния сервисов и перезапуск их при необходимости (с правильным разрешением зависимостей), пользовательские сервисы и другое.
> Даже не как в винде, а как в макоси и лучше. Функции
> эти - зависимости между сервисами, запуск сервисов по событиям (например вставили
> USB-аудиокарту - запустился PulseAudio), параллельный запуск сервисов, контроль состояния
> сервисов и перезапуск их при необходимости (с правильным разрешением зависимостей), пользовательские
> сервисы и другое.На сервере в стойке это всё не нужно.
Там не нужно правильно перезапустить сервис если он упадёт? O RLY? Ну тогда тебе и электричество не нужно - обойдешься лучиной.
Вы без балансировщика работаете, без резервных серверов?
Неужели в sysvinit linux нельзя никак было запустить сервис по событию, вставленной флешке например?
> Функции эти - зависимости между сервисами, запуск сервисов по событиям (например вставили USB-аудиокарту - запустился PulseAudio)
more /etc/devd.conf|grep service -B4
notify 0 {
match "system" "IFNET";
match "type" "LINK_UP";
media-type "802.11";
action "service dhclient quietstart $subsystem";
--# When a USB Bluetooth dongle appears, activate it
attach 100 {
device-name "ubt[0-9]+";
action "service bluetooth quietstart $device-name";
};
# Switch power profiles when the AC line state changes.
notify 10 {
match "system" "ACPI";
match "subsystem" "ACAD";
action "service power_profile $notify";
--
# it when the "user:postgres:swap:devctl=1G" rctl(8) rule gets triggered.
notify 0 {
match "system" "RCTL";
match "rule" "user:770:swap:.*";
action "service postgresql restart";
оно? Завистники еще и машину времени изобрели, чтобы незаметно стырить идеи:
man devd
HISTORY
The devd utility first appeared in FreeBSD 5.0
% grep -i "freebsd.*5\.0" /usr/share/misc/bsd-family-tree
FreeBSD 5.0 2003-01-17 [FBD]
> devdА теперь вот это недоudev выкини и всё то же самое - на чистом bsd init.
>> devd
> А теперь вот это недоudev выкини"Недо" оно потому что туда не встроили dbus и еще 100500 свистелок или потому что не прибили полуметровыми гвоздями?
> и всё то же самое - на чистом bsd init.
Выкинь для начала udev, который тоже появился задолго до системды.
И обоснуй заодно, почему ты приравниваешь системду к чистому иниту?
Свистелка это твоя devd. 4.4BSD прекрасно жила без неё. Если ты не понимаешь зачем нужны зависимости между сервисами, API и взаимодействие device fs с init, просто проходи мимо.
> Свистелка это твоя devd. 4.4BSD прекрасно жила без неё.Тоесть, возразить что-то по теме нечего?
> Если ты не понимаешь зачем нужны зависимости между сервисами,О, еще один рассказчик про отсутствие зависимостей в несистемде?
А зачем оно нужно? Расскажите, можно на примере.
Автоматический перезапуск упавшего сервиса, программный сишный API для регистрации сервиса в системе. Программный сишный API для чтения событий из системных журналов.
> Автоматический перезапуск упавшего сервиса,Не было такого в NT4. ...или я точно в склерозе?
Service Control Manager в NT 4 был https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0980скорее всего у него уже и параметр "автоперезапуск" был.
> скорее всего у него уже и параметр "автоперезапуск" был.[I]
> скорее всего[/I]Чё-т ты не убедил моего склерза. Автозапуск был - при загрузку системы чтоб.
А вот Авто-пере-, "перезапуск упавшего", вело-мото-фото...
...не припоминаю. [I]Вы фсйо врёти.
И в sysvinit нельзя было читать системный журнал??
Можно конечно, просто самому придётся писать разделение записей на поля и поиск с фильтрацией по источнику события.
Systemd начал разрабатываться практически сразу после того, как в совете директоров RedHat появились армейские генералы. Вполне логично рассматривать подобные "уязвимости" как прямое предназначение systemd. В нужный момент вызвать сбои в инфраструктуре вероятного противника - вполне себе привлекательное вложение для средств из оборонного бюджета США. Не вызывает удивления и то, что IBM, компания, которая практически с самого начала своего существования работала в тесной связи с военными разработками, вдруг решила приобрести RedHat...
Флот --> торпеды --> кибернетика --> ИБМ.Кто где когда появился и купил, всего лишь перекладывание дивидендов из общака в карман поближе.
Он же троллей нанял что системд на опеннете защищали.
Ох, пионерство. Пусть забавляются, короче. А мы подождём rust'овцев с redux'ом и прочими нескучностями.
Подождёте пару тысяч лет.
ну что ты, что ты - они быстрые. Или ты имел в виду - работающего, а не "компилируется же ж"?