uselessd — форк systemd

Часто этот формат менялся?

забанили в гугле

Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ...

Я не просил тебя перечислять слова, значения которых ты не понимаешь. Я попросил назвать фичи, необходимые системе управления демонами для функционирвоания.

uselessd — форк systemd (комментарий)

Этот формат совместим в обе стороны.

ок, как ты узнаеш что запущеный демон досихпор живой?

значения которых ты не понимаешь

Не стоит переходить на личности и хамить. For the record — так получилось, что я имел дело с каждым из указанных мной ядерных API, так что ты не только хамишь, но ещё и просто не прав.

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

Все указанные API необходимы systemd для функционирования. Опциональных там нет.

А ты то хоть знаешь, зачем в systemd нужен вебсервер и генератор qr-кодов? Они нужны для сислога.

верно!

Который можно было бы вполне сделать отдельным компонентом.

ну и как ты себе это представляешь?

вот система инициализации запускает демона. и демон пишет сообщения в stderr-поток. этот stderr-поток нужно писать в журнал.

нюанс в том что доступ к stderr-потоку от демона — имеет именно система инициализации.

ок, как ты узнаеш что запущеный демон досихпор живой?

man 7 signal

Все указанные API необходимы systemd для функционирования. Опциональных там нет.

Ты всё еще невнимателен.

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

То, что systemd не может собраться без кучи Linux-специфичных интерфейсов, общеизвестно. Так это проблема systemd. С какой стати это проблема ядра?

Я же тебя спрашиваю про систему управления демонами.

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

Интроцикл?

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

Если эти API используются в systemd — значит, там была необходимость сделать то, что без них сделать невозможно. Следовательно, единственным решением проблемы «systemd не работает под *BSD» является дописывание ядра *BSD.

> Который можно было бы вполне сделать отдельным компонентом.

ну и как ты себе это представляешь?

вот система инициализации запускает демона. и демон пишет сообщения в stderr-поток. этот stderr-поток нужно писать в журнал.

нюанс в том что доступ к stderr-потоку от демона — имеет именно система инициализации.

А теперь откроем документацию на daemontools, runit или s6 и почитаем, как это там сделано.

Если эти API используются в systemd — значит, там была необходимость сделать то, что без них сделать невозможно.

более вероятный вариант: автор(ы) systemd малокомпетентны.

какая наивность, а если демонов несколько, а если они форкаются так что непонятно кто чей парент?

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

Мы здесь обсуждаем отсутствие грамотного проектирования в systemd.

Если эти API используются в systemd — значит, там была необходимость сделать то, что без них сделать невозможно.

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

Я-то думал, ты возьмёшь доказать свои слова, а для тебя озвученная точка зрения — просто символ веры.

«Если этот алгоритм имеет сложность pow(n, 2), значит, именно такая сложность и является наилучшей, иначе сделать было невозможно.»

Верую, ибо абсурдно.

Отнюдь. Если эти API вообще существуют и были добавлены в ядро — значит, они делают то, что без них сделать затруднительно (т. е. они не пересекаются функциональностью с чем-то ещё).

uselessd — форк systemd (комментарий)

какая наивность

Наивность здесь только у свидетелей Пророка. Я всегда отвечаю за свои слова.

а если демонов несколько

Могу только посоветовать почитать «Си для чайников». Ну там, контейнеры: массивы, списки, ты понял.

если они форкаются так что непонятно кто чей парент?

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

Из того, что она решается при помощи control groups, никак не следует, что control groups необходимы. Служба управления демонами — это модель и алгоритмы, касающиеся непосредственно управления демонами. А задача «гарантировано убить всех потомков при остановке сервиса» — это механизм для одной из фич системы.

Фича может решать через control groups. Фича может решаться через jails. Фича может вообще никак не решаться на целевой платформе, тогда мы компилируем ПО без неё. Это азы проектирования, касающиеся, во-первых, отделения политики от механизмов и, во-вторых, graceful degradation. То, что Поттеринг забивает на это и то, что его последователи даже не понимают этих слов, говорит не о том, что «ядро BSD чего-то там должно», а о том, что Поттеринга и его последователей надо гнать метлой из профессии.

Советую начать с основ логики.

— Назовите фичи, необходимые системе управления демонами.
— Если эти API вообще существуют и были добавлены в ядро — значит, они делают то, что без них сделать затруднительно (т. е. они не пересекаются функциональностью с чем-то ещё).

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

Универсальные методы портирования софта от devzero: выкидываем из софта весь софт, что осталось - портируется без проблем на любую платформу. Правда вот вопрос «зачем» так и остался неясен.

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

Для systemd — всё из перечисленного. А абстрактный «инит» мы здесь и не рассматриваем.

Уникальная интерпретация systemd от alpha: systemd решает только и единственно проблему гарантированной остановки форкающихся служб; все остальные вопросы менеджмента служб уже успешно решались иными системами этого же класса.

Однако!

Такого я еще не слышал даже на ЛОРе.

Для systemd — всё из перечисленного.

И ты ещё спрашиваешь, почему systemd обзывают ненужным раздутым гуано?

Мне она втирала, что systemd - это хорошая замена скрипту из 3 строк на баше для того, чтобы у неё сервис на Java перезапускался как надо.
Ынтерпрайз, фигли.

При чём здесь раздутость? И кто ещё толстенький и зелёненький...

I also find that the Linux kernel has a lot of cool features that can make applications faster, safer and simpler, and we often don’t use those in the name of portability. There is an accept4 syscall that lets you accept a connection on a socket and sets O_CLOEXEC atomically. The epoll mechanism with timerfd and signalfd does most of what many complex userspace event loops do in many thousands of lines of code. We need to embrace all the new features the kernel offers and not insist on some outdated lowest common denominator.

больше того, туда можно вообще бинарник положить. лишь бы он отзывался на стандатрные аргументы start/stop/restart/reload/что-там-еще

I also find that the Linux kernel has a lot of cool features that can make applications faster, safer and simpler, and we often don’t use those

ИЧСХ, systemd как и недопульса в большинстве случаев изобретает велосипед вместо использования существующих и рабочих вещей, жирненький intelfx.

Так я ж и говорю: доработать или исправить systemd нет никакой возможности. Он написан Пророком, а то, что написано Пророком, — священно. Библия!

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

Согласен, НО там оно не уместно(вот нормальный пример использования союза «но»).

нюанс в том что доступ к stderr-потоку от демона — имеет именно система инициализации

Ну продолжай свою мысль, не нужно останавливаться на полпути :) Напомню, что в systemd journald - отдельный процесс.

Есть и другие вопросы, например при повреждении файла журнала journald нет утилиты для восстановления

Так при подписывании подругому и быть неможет. Это вопрос: применять ли защиту от подменыю Хочешь возможность востановления части, в ущерб защите от подмены - настрой на текст.

Если эти API используются в systemd — значит, там была необходимость сделать то, что без них сделать невозможно.

более вероятный вариант: автор(ы) systemd малокомпетентны.

Более верояно, что малокомпетентны нытики на форуме.

у меня fstab уже пустой

А куда писать noatime и discard?

Для чего используют-то? Что ими шифровать?

а дышать мне при этом можно?

А что, процесс-родитель не в курсе?

ну так вот systemd стартует юнит и в качестве stderr fd передается дискриптор от journald

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

Для чего используют-то? Что ими шифровать?

официальная информация с сайта Sony:

Certain pre-loaded content on your device may also be inaccessible due to the removal of DRM security keys. The secure user data partition may also become inaccessible, and you will not be able to get any more official software upgrades if you unlock the boot loader.

> нюанс в том что доступ к stderr-потоку от демона — имеет именно система инициализации

Ну продолжай свою мысль, не нужно останавливаться на полпути :) Напомню, что в systemd journald - отдельный процесс.

ну там наверное файловый дескриптор передаётся от одного systemd-процесса к другому systemd-процессу (ядро linux умеет передавать файловые дескрипторы между процессами, ну или даже быть может и любой posix умеет это)

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

а что мы получим когда заставим главный процесс (pid-1) передавать файловый дескриптор — к чужеродной системе журналирования? кто будет согласовывать протокол сообщения между ними? :-)

демон может вести себя как угодно все случаи всеравно без cgroups не отследиш.

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

MS'овские методы какие-то насаждения своих поделий

Red Hat агент Microsoft ;)

Red Hat — американская компания, выпускающая решения на основе свободной операционной системы Linux: Red Hat Enterprise Linux (распространяется по годовой подписке) и Fedora (распространяется свободно), а также другие программные продукты и услуги на основе открытого исходного кода (в том числе среду компиляции и выполнения приложений Linux (POSIX) под ОС Microsoft Windows — Cygwin).

это в общем-то и не только о systemd может говорить

Может. Но ничто больше на процесс загрузки так фатально не влияет. Кроме ядра, конечно, но ядро старое остаётся рядом по-умолчанию. В отличие от. :-)

Их пишут ментейнеры как могут.

Они тоже авторы ПО в некотором роде.

Когда напишут на перле, тогда можно будет сравнить перловое решение

Я про init-скрипт, если что.

Но пока перлового решения нет и не предвидится

Переписать на Перле - минутное дело. Речь именно про init-скрипт для отдельно взятого демона. Это не имеет отношения к работоспособности самого sysvinit ну никак.

Но пока их пишут на шелле с использованием хреновой тучи вспомогательных утилит

Это никак не отражается на старте системы. Это отражается только на старте одного конкретного демона. Сюрприз ?

Система, а точнее юзерспейс — это совокупность демонов. Сюрприз?

Так ещё при Петре Первом писали.