Ubuntu продолжает интеграцию компонентов systemd

и не просто запилили, но еще и завязали все друг на друга

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

Я задам любимый мой вопрос: ты видел его исходники

А давай я задам тебе этот вопрос - ты видел исходники systemd? Если да, то как впечатление, например, от src/core/service.c? По-моему, 4k строк в лучших индусских традициях. Как можно не влюбиться в функции по 200 строк и в эти проверки условий:

       if (state != SERVICE_START_PRE &&
            state != SERVICE_START &&
            state != SERVICE_START_POST &&
            state != SERVICE_RELOAD &&
            state != SERVICE_STOP &&
            state != SERVICE_STOP_SIGTERM &&
            state != SERVICE_STOP_SIGKILL &&
            state != SERVICE_STOP_POST &&
            state != SERVICE_FINAL_SIGTERM &&
            state != SERVICE_FINAL_SIGKILL &&
            state != SERVICE_AUTO_RESTART)

Ладно, и я тоже написал свою долю быдлокода, но, блин, я хотя бы не пишу руководств по кодированию на Си %)

ну инновации там есть, вот например, цгруппы, в других системах их не было ибо не переносимы и нафиг надо, в опенрц с полгода назад появилась опциональная поддержка группировок сервисов по цгруппам, и в следующем релизе будет поддержка лимитов и прав через цгруппы, так же опциональная, т.е. на bsd этого кода не будет в принципе, так же для тех, кто не включит это в конфиге. Но при этом systemd идет дальше и использует хранилище внутри файловой системы cgroups для того, чтобы хранить там pid главного процесса, т.е. чистая замена /run/service.pid, с тем отличием, что теперь этот параметр лежит в расширенных аттрибутах /sys/fs/cgroups/systemd/service/, логических отличий нет, функциональные, то что теперь это cat-ом не посмотришь, да и read привелегии не выдашь, ну и то, что это не переносимо на платформы без systemd, я вот лично не понимаю нафига так делать, в открытом доступе инфы нет, спрашивать у авторов, как-то не охота, да и боюсь нарваться на сообщения вида «Прогресс! Инновации! Одержание! Разрыхление! Заболачивание!».

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

уже разжевывалось в топике

как я понял, safe_mysqld выходит со соотв статусом,

Ненене, ты немного не так понял. mysqld_safe запускается, дает мускулу команду на подъем и сразу после этого выходит с успешным статусом. Мускул начинает свой небыстрый занудный старт. Инит понимает, что демон стартовал и продолжает. Тем временем мускул становится доступным только секунд через пять.

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

Там есть места похуже (% Впрочем, конкретно это еще более-менее. grepable, хотя бы

с тем отличием, что теперь этот параметр лежит в расширенных аттрибутах

Это не совсем так, но тем не менее, это можно посмотреть cat'ом. Это ж файловая система все-таки. Это нужно в том числе для получения уведомлений о смерти

спрашивать у авторов, как-то не охота, да и боюсь нарваться на сообщения вида «Прогресс! Инновации! Одержание! Разрыхление! Заболачивание!».

И «Nobody forces you to use any of this software! It's open source! You get it for free! You get it completely for free!!11»

http://www.youtube.com/watch?v=CmPKDeo9Oow

Там есть места похуже (%

Именно в src/core?

Да. Например, в manager.c и transaction.c лучше не смотреть. Вообще, когда я первый раз увидел этот код, я немного испугался. Но в этом что-то есть... :D

Ох, слушай, извини правда. Я тебя с Кернелом перепутал. Блин, откуда вы таких аватар понабрали?

Блин, откуда вы таких аватар понабрали?

У меня же нет аватары O_o

4. Extended attribute usage
===========================

cgroup filesystem supports certain types of extended attributes in its
directories and files.  The current supported types are:
        - Trusted (XATTR_TRUSTED)
        - Security (XATTR_SECURITY)

Both require CAP_SYS_ADMIN capability to set.

Like in tmpfs, the extended attributes in cgroup filesystem are stored
using kernel memory and it's advised to keep the usage at minimum.  This
is the reason why user defined extended attributes are not supported, since
any user can do it and there's no limit in the value size.

The current known users for this feature are SELinux to limit cgroup usage
in containers and systemd for assorted meta data like main PID in a cgroup
(systemd creates a cgroup per service).

это катом смотрится?

ConsoleKit ... systemd-logind

Чувствую я, что Линукс с каждым годом из простой управляемой руками системы превращается в виндоподобный набор сервисов. Несколько лет назад мне для поднятия сети достаточно было написать ifup eth0, теперь надо шариться по апплетам и др.

Есть где-нибудь доступная документация, как в современных линуксах все эти ***d и ***Kit взаимодействуют друг с другом, и кто за что отвечает? Желательно с диаграммочками.

Как это нет аватары? А че за синяя хрень на ножках у меня вместо твоей аватары?

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

...но потом привык.

Правда, я не вижу ничего очень уж страшного в transaction.c Или оно страшное не внешне, а по сути?

Не, это можно посмотреть getfattr, по идее, если есть. Но причем тут?

Фига. Оказывается ЛОР умеет всякую хрень вместо аватар подставлять, и у меня в настройках стоял какой-то monsterid, который и сыграл со мной эту злую шутку. Признаю, что оклеветал тебя незаслуженно, вот тебе в подарок: http://upload.wikimedia.org/wikipedia/commons/f/f6/Atari_800XL.jpg

Ну, меня пугают рекурсивные ф-ии с 10ю параметрами, которые впоследствии расширяются в ширину :) Но то такое..

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

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

Да. И systemd - еще один щаг (правда, самый большой на сегодня) в этом направлении.

И systemd - еще один щаг (правда, самый большой на сегодня) в этом направлении.

Ты проспал появление гнома и кде?

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

Как человек, знакомый с кодовой базой, скажи - зачем куча программ вынесена в собственные подкаталоги? Я бы понял, если бы они были разбиты на модули, но мы имеем такие жемчужины, как systemctl.c на 5к строк.

Ты проспал появление гнома и кде?

Гном? КДЕ? Это те жирные DE, на которые всем пофиг? Мне пофиг на них. А вот на базовую систему мне не пофиг.

Вот поэтому я, например, вообще отключил отображение аватар.

Изначально сделал это для того, чтобы ЛОР адекватно смотрелся на смартфоне, но потом увидел, что и на десктопе без аватар намного лучше.

1) этот код мне понятен

2) это отнють не самый страшный код.

3) Функция в 200 строк это не проблема.

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

В общем, ты укрепил мою верю что товарищи всё верно делают.

уже разжевывалось в топике

можно ссылочку?

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

1) этот код мне понятен

Ну да, ну да. А повторенный в нескольких местах, он становится в несколько раз понятнее.

Тогда на systemd молиться надо потому что если там дело ограничивается только таким то это прямо таки образец для подражания.

Даже если этим ограничивается, это значит, что код как минимум созрел для рефакторинга. Но лично у меня нет оснований думать, что ограничивается этим.

В общем, ты укрепил мою верю что товарищи всё верно делают.

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

P.S. в то, что systemd модульный, ты теперь тоже веришь еще больше?

По-моему, аватара немного говорит о человеке, не хочу совсем отключать. Но автоматические аватары - зло, конечно.

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

можно ссылочку?

прямая ссылка на виновника торжества:

https://plus.google.com/115547683951727699051/posts/jgT3DuQf63a

Я конечно может чего не это, но у группы нет понятия основного пида. Группа это просто группа пидов. Основной пид юнита хранит системде в своем внутреннем состоянии

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

прямая ссылка на виновника торжества

И? Там написано почему так сделано.

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

Пока у нас есть свободные компиляторы Си, волноваться нечего

fixed

код как минимум созрел для рефакторинга

Я не верю в существование кода который нельзя улучшить. Главное чтобы было что улучшать потому что в большинстве случаев мне хочется всё что есть выкинуть нахрен и сделать с нуля.

в то, что systemd модульный, ты теперь тоже веришь еще больше?

Я верю что у systemd есть будущее.

Я верю что у systemd есть будущее.

О, в это я тоже верю. Это будущее будет большим и светлым. Redhat гарантирует.

Не знаю вобщем. Мне кажется это не соответствует действительности. main_pid хранится в состоянии сервиса.

Если получить в консоли:

eval `systemctl show -p MainPID acpid.service`; echo $MainPID
1683

Сейчас основной потребитель системде это арч. Так что такое :]

Сейчас основной потребитель системде это арч

Основной по какому критерию - шуму? Тогда конечно.

а стрейс на него наслать можешь?

Redhat гарантирует.

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

На что? На systemctl? Я и так скажу что он делает — подключается к systemd, тот отдает состояние сервиса, вместе с этим полем

ага, вот, например, neon или т.п. Плюс обычно забивают на другие дистры, в итоге если в списке коммитеров программы много народу с @redhat.com, значит - знай будет куча проблем, и не дай Б-г придётся патчить, радость на пару дней обеспечена. Хотя есть и исключения, и в целом вклад редхата очень важен.

Основной по какому критерию - шуму? Тогда конечно.

Ну ты просто остряк. Разумеется по количеству инсталляций

хм.. ок, ясно, просто есть подозрение, что systemd берёт пид из фс (исходники сейчас смотреть не хочу).

Основной по какому критерию - шуму? Тогда конечно.

Ну ты просто остряк.

Я такой, да.

Разумеется по количеству инсталляций

Что такое, Арч обошел суммарное количество инсталляций Федоры и опенЗюзикса? Откуда данные.

Можно пример, пажалста

Пжалста - вот я настраивал недавно lxc, выяснилось что shutdown скрипты делают remount той fs на которой находятся. Пришлось побыстрому фиксить.
systemd решает эту проблему тем что там как амне помнится просто systemd детектит контейнер ... и не делает все shutdown операции. И что делать если мне только remount ненужен? :D

Ага - править бинарь.

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

Какой-то ночной бред.

То есть, как я понимаю, вы таки действительно кхм, тугодум, раз не поняли такого примера. :D Попробую прояснить.

Представьте что у вас полсотни серверов с *разными* мелкими правками бинаря systemd. Это приводит к тому что вам, фактически, самому, приходится поддерживать множество бинарных пакетов.

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