LINUX.ORG.RU

uselessd — форк systemd

 , ,


6

8

uselessd — попытка урезать systemd до базовых функций: initd, супервайзор процессов, система зависимостей — но без изоляционизма и агрессивной навязчивости (когда комбайн лезет всюду и делает себя незаменимым). Также обеспечивается поддержка платформ без glibc и планируется поддержка ядер отличных от Linux. За основу взят systemd 208.

На сайте перечислены следующие ключевые отличия:

  • Совместимость с musl и uClibc.
  • Отказ от journald, libqrencode и libmicrohttpd. Отказ от бинарных логов. Лог по умолчанию идёт в LOG_TARGET_KMSG_OR_SYSLOG.
  • libudev и udevd необязательны. Ноды устройств можно создавать чем угодно.
  • Удалены избыточные типы юнитов: devices, timers, swaps, mounts, automounts.
    • Device units завязаны на udev и вместо них можно обойтись правилами udev.
    • Timer units не нужны, так как есть cron и его новые аналоги, например fcron.
    • Swap units удалили как сложные, агрессивные и малополезные. Рекомендуют пользоваться настройками sysctl и util-linux.
    • Automount units и mount units удалены для упрощения. Рекомендуют autofs или Berkeley Automounter.
  • Удалены вспомогательные демоны (hostnamed, timedated, localed, logind...) Удалены генераторы кроме getty-generator и rc-local-generator, так как они дублировали имеющийся функционал или были привязаны к удалённым типам юнитов.
  • Удалены средства настройки систем MAC/ACL, включая SMACK, IMA и SELinux, чтобы не загромождать и не привязываться к одной системе. Для совместимости с существующими конфигурациями остались поддержка SELinux в D-Bus API и SMACK в сокетах.
  • systemd-fsck заменили вызовом /sbin/fsck.
  • Частичная поддержка FreeBSD.

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

Новость на OpenNet

Исходные тексты

>>> Сайт проекта

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от Deleted

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

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, ...

anonymous ()
Ответ на: комментарий от intelfx

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от goingUp

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

верно!

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

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

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

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

user_id_68054 ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

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

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

Deleted ()
Ответ на: комментарий от anonymous

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

Интроцикл?

anonymous ()
Ответ на: комментарий от Deleted

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

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

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

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

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

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

Deleted ()
Ответ на: комментарий от intelfx

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

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

anonymous ()
Ответ на: комментарий от Deleted

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

anonymous ()
Ответ на: комментарий от intelfx

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от anonymous

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

intelfx ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от intelfx

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

Однако!

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

Deleted ()
Ответ на: комментарий от Deleted

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

devl547 ★★★★★ ()
Ответ на: комментарий от devl547

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

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.

intelfx ★★★★★ ()
Ответ на: комментарий от AS

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

PerdunJamesBond ()
Ответ на: комментарий от intelfx

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.

devl547 ★★★★★ ()
Ответ на: комментарий от intelfx

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

Deleted ()
Ответ на: комментарий от Quasar

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

ya-betmen ★★★★★ ()
Ответ на: комментарий от user_id_68054

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

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

goingUp ★★★★★ ()
Ответ на: комментарий от goingUp

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от redgremlin

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

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

anonymous ()
Ответ на: комментарий от goingUp

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

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

anonymous ()
Ответ на: комментарий от vitalif

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

официальная информация с сайта 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.

Loki13 ★★★★★ ()
Ответ на: комментарий от goingUp

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

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

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

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

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

user_id_68054 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от fero

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

Red Hat агент Microsoft ;)

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

EvilFox ★★ ()
Ответ на: комментарий от alpha

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

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

AS ★★★★★ ()
Ответ на: комментарий от x3al

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

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

AS ★★★★★ ()
Ответ на: комментарий от redgremlin

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

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

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

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

AS ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

AS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.