LINUX.ORG.RU

systemd 218

 ,


3

5

12 декабря был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала и управления сессиями пользователей. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые задачи по управлению системой — от настройки подсистемы VT (systemd-vconsole-setup) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Список изменений:

  • Все компоненты systemd, обладающие конфигурационными файлами в /etc/systemd, теперь умеют считывать настройки из соответствующих *.d-директорий в /usr/lib, /run и /etc.

    Например, /etc/systemd/system.conf можно дополнять из /{usr/lib,run,etc}/systemd/system.conf.d/*.conf.

  • Добавлена команда systemctl edit, которая позволяет редактировать unit-файлы (используется редактор, указанный в переменной окружения $EDITOR).

    Возможные режимы работы таковы:

    • (по умолчанию): «режим дополнения», т. е. редактирование нового drop-in'а (создаётся и открывается /etc/systemd/system/$unit.d/override.conf)
    • --full: «режим исправления», т. е. редактирование всего юнит-файла (он предварительно копируется в /etc/systemd/system, если необходимо)
    • --runtime: «режим временных изменений», т. е. вместо /etc используется /run и все внесённые изменения живут только до перезагрузки
  • Команда systemctl is-enabled теперь выводит «indirect» вместо «static» (при этом код возврата равен 0) в тех случаях, когда секция [Install] юнита содержит только директивы Also=, т. е. когда сам юнит не может быть включен, но «включает» другие юниты.
  • Команда systemctl status ЮНИТ теперь выводит также и «предлагаемое» состояние юнита согласно preset'ам. Это показывает, должен ли юнит быть включен согласно дистроспецифичному дефолту.

    Пример:

    $ grep -R remote-fs.target /usr/lib/systemd/system-preset
    /usr/lib/systemd/system-preset/90-systemd.preset:enable remote-fs.target
    
    $ systemctl status remote-fs.target
    ● remote-fs.target - Remote File Systems
       Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; disabled; vendor preset: enabled)
    

  • Команда systemd-run теперь поддерживает отложенный запуск команд в стиле at(1) (параметры командной строки --on-calendar и аналогичные). Это реализовано с помощью создания временного timer-юнита наряду с основным service-юнитом (поддержка создания timer-юнитов как раз была добавлена в API systemd).
  • В команде busctl, предназначенной для работы с шиной D-Bus, добавлены следующие подкоманды и параметры командной строки:
    • busctl capture (захват всех данных, проходящих через шину, в формате libpcap)
    • busctl tree (отображение дерева объектов для конкретного сервиса или для всех сервисов на шине)
    • busctl introspect (отображение подробной информации о конкретном объекте на шине)
    • busctl call, busctl get-property и busctl set-property (предназначение очевидно из названий)
    • busctl --augment-creds= (включение или отключение сбора вспомогательных данных о процессах на шине из /proc)

      Последняя опция по умолчанию включена, но в некоторых случаях это может привести к race conditions, поэтому и была добавлена возможность её отключения.

  • В команде journalctl добавлены параметры командной строки --vacuum-size= и --vacuum-time=, позволяющие принудительно удалить старые файлы журнала. Как легко понять из названий параметров, критерием очистки может быть или суммарный размер файлов журнала, или давность сообщений в конкретном файле.
  • В команде systemd-nspawn добавлены параметры командной строки --link-journal=try-guest и --link-journal=try-host, которые работают аналогично значениям guest и host (а именно — включают объединение журналов хоста и контейнера), но не возвращают ошибку, если на хосте ведение постоянного журнала отключено.

    Параметр командной строки -j теперь является синонимом для --link-journal=try-guest.

  • Команда systemd-inhibit при отображении списка активных ингибиторов теперь поддерживает фильтрацию по типу (block или delay).
  • Для каждой директивы вида ConditionXYZ= в секции [Unit] unit-файлов добавлена аналогичная директива AssertXYZ= в той же секции.

    Отличие между ними состоит в том, что невыполнение Condition-директив приводит к пропуску (игнорированию) юнита, а невыполнение Assert-директив переводит юнит в состояние «failed».

  • В секциях [Scope] и [Service] unit-файлов добавлена директива Delegate=, разрешающая процессам юнита самостоятельно управлять своим поддеревом контрольных групп.
  • В секции [Service] unit-файлов добавлена директива SmackProcessLabel=, позволяющая установить для всех процессов юнита указанную метку SMACK64.
  • Директива ConditionSecurity= unit-файлов теперь может принимать значение audit, что будет приводить к проверке доступности audit-подсистемы ядра.
  • systemd-coredump теперь собирает и кладёт в журнал вместе с core-дампом некоторое количество метаданных об упавшем процессе, а именно:
    • контрольные группы, к которым принадлежал процесс (/proc/$PID/cgroup)
    • список переменных окружения и их значения (/proc/$PID/environ)
    • карту адресного пространства процесса (/proc/$PID/maps)
    • рабочую директорию (/proc/$PID/cwd)
    • корневую директорию (/proc/$PID/root)
    • состояние процесса (/proc/$PID/status)
    • список открытых файловых дескрипторов (/proc/$PID/fd)
  • journald теперь умеет собирать сообщения audit-подсистемы ядра (с обработкой сопутствующих метаданных) и записывать их в общий лог. В частности, это означает, что journalctl становится альтернативой традиционному audit-клиенту ausearch.
  • systemd-networkd теперь поддерживает:
    • конфигурирование VXLAN-устройств (секция [VXLAN] netdev-файлов)
    • указание «стоимости» портов bridge-устройств (директива Cost= в секции [Bridge] network-файлов)
    • настройку правил IP source routing (директива Source= в секции [Route] network-файлов)
    • выбор сетевого интерфейса по его исходному имени (до переименования; директива OriginalName= в секции [Match] link-файлов)
    • изменение MAC-адреса и MTU интерфейса из network-файлов (директивы MACAddress= и MTUBytes= в секции [Link] network-файлов)
  • В systemd-networkd начата работа по реализации протокола PPPoE.
  • NSS-модуль nss-myhostname теперь ресолвит имя «gateway» в IP-адрес шлюза по умолчанию. Если таковых несколько — они сортируются по значению метрики.

    Отмечу, что это изменение не нарушает работу конфигураций, в которых имя «gateway» уже как-либо используется, поскольку модуль nss-myhostname обычно идёт последним в списке NSS-модулей.

  • macvlan-устройства, создаваемые systemd-nspawn внутри контейнеров, теперь имеют стабильные MAC-адреса (в том смысле, что они не будут изменяться каждый раз).
  • systemd-cryptsetup-generator теперь поддерживает указание key-файлов и назначение имён для отдельных устройств из командной строки ядра (luks.key=<UUID>=<имя файла> и luks.name=<UUID>=<назначаемое имя устройства>).
  • В systemd-tmpfiles добавлено действие t — назначение файлу произвольных расширенных атрибутов (xattrs).
  • systemd-localed теперь опционально зависит от libxkbcommon. Эта библиотека будет использоваться для проверки корректности устанавливаемых настроек раскладки клавиатуры X11 (напр., с помощью localectl set-x11-keymap).
  • В systemd-hostnamed список текстовых описаний типов системы (chassis type) был пополнен значением «embedded».
  • systemd-rfkill теперь ассоциирует запоминаемое состояние rfkill'а не с его именем (rfkill0, rfkill1, ...), а с комбинацией его типа (wlan, bluetooth, ...) и свойства ID_PATH.

    Это связано с тем, что имя rfkill'а не обязано сохраняться между перезагрузками или переподключениями устройства. Более того, в последнем случае оно никогда не остаётся прежним.

  • База данных аппаратного обеспечения (hwdb) udev'а теперь содержит базу данных разрешений оптических сенсоров мышей. Она будет использоваться в libinput для автоматической коррекции ускорения курсора.

    Ситуация более подробно описана в этом сообщении.

  • systemd теперь умеет корректно обрабатывать ситуации, в которых система одновременно
    • не имеет файла /etc/machine-id
    • запускается с корневой ФС в режиме «только чтение»

    Для обработки этих случаев была добавлена вспомогательная утилита systemd-machine-id-commit, которая запускается сразу после перемонтирования корневой ФС в режим «чтение и запись» и атомарно перемещает временный файл machine-id из tmpfs в /etc/machine-id.

>>> Объявление о релизе

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 7)

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

Так что я лучше запасусь попкорном и посмотрю как за дело возьмутся БСДшники.

Успехов.

Не существует, но близкие к этому состоянию проекты есть.

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

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

Нее, это не фантазии. Раз ты что-то там говоришь про объективность и субъективность и ставишь под вопрос результаты ажно двух голосований (сначала среди TC, потом среди всех разработчиков) — стало быть, уверен, что знаешь лучше них. Следовательно, считаешь, что мог бы решить вопрос лучше них. QED.

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

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

Следовательно

Что следовательно для тебя, следовательно исключительно для тебя и ничего не меняет.

А пойти на хрен всёй-таки придётся

Только в твоих фантазиях.

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

Где голос core kernel developer'a - равнялся голосу мантайнера пакета фортунок.

Хатчгинс и Фрейзер поставили на первое место вариант 4, который в итоге и победил. Ах да, их же купил коварный Ред Хат.

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

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

А они и не должны «заворачивать» потомков, просто процесс надо не от рута стартовать, cgroups внезапно оунером процесса и оперирует.

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

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

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

это ж как пукан должен был

Да, молодое поколение только категориями задницы мылить и может. Поди ассенизатором поработай, раз у тебя склонность.

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

Хатчгинс и Фрейзер поставили на первое место вариант 4, который в итоге и победил

В каком итоге? Напомнить что там происходило? Голосовали-переголосовывали пересрались и пропихнули. Потом в конце-концов мантайнер системд поджал хвост и как-то все сдали назад. И все встало на свои места в дебиане по-прежнему влегкую выбирается любая система старта. Кое-кто уже начал пилить более правильную замену системд, но пока у них все на стадии драфтов

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

вследствие чего количество твоих собеседников уменьшается на один.

Да это потеря-потерь.

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

Дак голосовали про дефолт. А не про то, что бы выкинуть альтернативы.

Пилится замена - удачи. Раз делают, значит оно кому-то нужно. Если не взлетит - значит не нужно.

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

Теперь давай посмотрим на простые факты:
systemd приняли в федору для того, что бы приготовить его к RHEL8.
Иначе говоря, редхету, который оказывает коммерческую поддержку кучи серверов, нужен был такой инструмент.
Федора-же, по сути, тестовый полигон для экспериментов редхет. Это никто и никогда не скрывал.
Debian, после всех голосований, выбрал системд своим дефолтом. И я бы не сказал, что там дураки, которые документацию не читали, голосовали. Основные опасения были чисто политические. С технической стороны он всех устраивал.
Для дебиана у systemd было только два недостатка:
1) Работает только под линуксом.
Единственный значимый довод.
2) У дебиана нет достаточного количества людей, что бы устроить технический паритет с редхатом.
Ну, тут дебиану не привыкать. Дистрибутив он хороший, однако это именно дистрибутив. Они не особо заморачиваются по поводу написания софта. Те, программистов там не много. Зато мейнтенеров много.

Теперь посмотрим на остальные дистрибутивы.
0) Все что базируется на RHEL (Fedora, CentOS, etc) - либо уже на systemd, либо переходит на него.
1) Ubuntu - Космонавт сказал что пойдет за дебианом и будет использовать системд.
2) Gentoo - пилят свой, особый велосипед.
3) Slackware - с их темпами и их подходу к дистростроению, этот срач не критичен. Точнее - он до них лет через 5 дойдет, не раньше.
4) Arch - systemd по дефолту.
X) есть еще куча карликовых дистров, которые особо на ситуацию не влияют.
Большое количество мейнтенеров проверило, обсудило и приняло systemd.
Иначе говоря, никто не пихает вам системд. Просто люди, которые работу работают берут системд.
Или ты сейчас расскажешь, как именно Леннарт пихает системд в каждый дистр?

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

Точнее - он до них лет через 5 дойдет, не раньше.

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

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

Для дебиана у systemd было только два недостатка:

1) Трудности с сопровождением пакетов под несколько систем инициализации, поскольку systemd давно уже не только система инициализации. И его использование затрагивает изменение слишком большое кол-во пакетов.

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

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

ну так запусти свой апач не из под рута на 80

root     10563  0.0  0.5   5932  2856 ?        Ss   08:23   0:00 /usr/sbin/apache2 -k start
www-data 10565  0.0  0.3   5720  2040 ?        S    08:23   0:00 /usr/sbin/apache2 -k start
www-data 10569  0.0  0.4 227340  2312 ?        Sl   08:23   0:00 /usr/sbin/apache2 -k start
www-data 10570  0.0  0.4 227348  2312 ?        Sl   08:23   0:00 /usr/sbin/apache2 -k start
ioway
()
Ответ на: комментарий от anonymous

не из-под рута, ага

Этот процесс - обычный бридж. Реальная работа которую надо ограничивать выполняется от пользователя www-data и успешно отруливается в cgroups, проблема с cgroups и инит высосана из пальца.

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

1) Трудности с сопровождением пакетов под несколько систем инициализации, поскольку systemd давно уже не только система инициализации. И его использование затрагивает изменение слишком большое кол-во пакетов.

Там всего сопровождения, взять готовый юнит-файл или написать его. 10 минут работы.

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

Оуч. И какая инит-система обладает этими качествами? Корявый autoexec.bat (aka sysvinit)?

Есть более крутая штука: http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/
И это намного важнее.

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

Нет наоборот, я буду продолжать отравлять твое «виртуальное» шествие по лору.

Считаешь это достойной целью своего существования?

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

Убунта наняла разраба на фултайм - и он будет пилить сам
системд.

https://launchpad.net/~serge-hallyn/ archive/ubuntu/cgmanager Вот этого чувака наняли cgmanager пилить.

Вообще-то я не напрягусь и быть дистростроителем. Благо
именно этим я и развлекался в свободное время.

Какова популярность вашего дистра?

http://www.markshuttleworth.com/archives/1316
Марк сказал, что больше пилить systemd-shim не будут. И
перейдут на чистый systemd.

Сорри, но вы как читаете вообще?

We’ll certainly complete work to make the new logind work without systemd as pid 1. I expect they will want to bring systemd into Ubuntu as an option for developers as soon as it is reliably available in Debian, and as our default as soon as it offers a credible quality of service to match the existing init.
[/quote]
Ещё вопросы? :)

> Как я и говорил, все и так идет так как мне надо.
А зачем вам это надо? Пользуйтесь тем, что дистр даёт.

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

Убунта наняла разраба на фултайм - и он будет пилить сам
системд.

https://launchpad.net/~serge-hallyn/ archive/ubuntu/cgmanager Вот этого чувака наняли cgmanager пилить.

Вообще-то я не напрягусь и быть дистростроителем. Благо
именно этим я и развлекался в свободное время.

Какова популярность вашего дистра?

http://www.markshuttleworth.com/archives/1316
Марк сказал, что больше пилить systemd-shim не будут. И
перейдут на чистый systemd.

Сорри, но вы как читаете вообще?

We’ll certainly complete work to make the new logind work without systemd as pid 1. I expect they will want to bring systemd into Ubuntu as an option for developers as soon as it is reliably available in Debian, and as our default as soon as it offers a credible quality of service to match the existing init.
Ещё вопросы? :)

Как я и говорил, все и так идет так как мне надо.

А зачем вам это надо? Пользуйтесь тем, что дистр даёт.

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

Считаешь это достойной целью своего существования?

Чего? Кто тебе сказал что это вообще какая-то цель?

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

То есть нет никаких проблем с заменой systemd upstart'ом как
PID 1

С этого места - по подробнее. Как это, нет проблем, если шимы ещё не доделали? Вы поймите, если бы не было проблем, то это сделали бы хотя бы опционально. Если вообще не по дефолту, ведь, несмотря на большее кол-во фич в системд, далеко не все разработчики дебиана считают, что эти фичи столь уж существенны для ближайшего релиза.

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

Не согласен. Я цитировал вот это:

Rather, we're talking about whether or not to swap out a core component of
an existing integrated ecosystem with a component that _we like better_.

Now, I am generally on the side that says loose coupling of ecosystems is
an inherent good.
Из этого следует и первая часть.

Так переход-то и состоит во впиливании systemd как PID 1!
Остальными частями systemd (udev, logind...) upstart
обмазался даже ещё до поднятия вопроса о системе
инициализации в Debian.

Гы, так вы поймите, это - вынужденный шаг. Какое-то время эти обвязки (удев, логинд) работали (через шим?), но теперь, когда добавились cgroups - работоспособность снова похерилась. Теперь им пришлось переходить на системд-пид1 лишь только чтобы всё снова заработало. А то, что они снова будут оживлять эти компоненты _без_ системд-пид1 - нам только что kir2yar поведал ссылкой, см сообщения выше.

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

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

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

Вот посуди сам, даже когда glib сломали memcpu

Не сломали, а починили. Эта оговорка много говорит о тебе и фанатиках системд.

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

Ааа, когда в glibc поломали кучу легаси ради блага — это хорошо, а когда в systemd поломали (да и то не поломали, а всего лишь задепрекейтили) кучу легаси ради блага — это плохо?

Двуличность, сэр.

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

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

ага ага :)

тяжелые сервисы и ценные данные на 15.04 :) Ну ну

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

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

Да это же просто секта! :)

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

systemd 218 (комментарий)

Нет наоборот, я буду продолжать отравлять твое «виртуальное» шествие по лору.
Чего? Кто тебе сказал что это вообще какая-то цель?

Не хочу тебя огорчать, но у тебя всё очень плохо. Совсем плохо.

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

Ааа, когда в glibc поломали кучу легаси ради блага — это
хорошо, а когда в systemd поломали

Не сравнивайте ж с пальцем. :) В глибц это поломали временно, и по ошибке. Когда Линус им вкатил по самые гланды - сразу добавили версионирование на символ memcpy, чтобы и старые проги нормально работали со своей, старой версией. А так-то да, тамошний маинтейнер глибца был ещё по-хлеще Поттеринга, и всех посылал на 3 буквы.

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

Не хочу тебя огорчать, но у тебя всё очень плохо. Совсем плохо.

Покажись врачу.

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

когда в systemd поломали (да и то не поломали, а всего лишь задепрекейтили) кучу легаси ради блага

Нет. Просто поломали.

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

С этого места - по подробнее. Как это, нет проблем, если шимы ещё не доделали?

Уже доделали.

Вы поймите, если бы не было проблем, то это сделали бы хотя бы опционально.

Это уже так и есть: можно установить systemd-sysv, что приведёт к использованию systemd как PID 1, а можно установить systemd-shim и, скажем, upstart или sysvinit в качестве PID 1. В любом случае всё будет работать.

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

Из этого следует и первая часть.

Как и ожидалось, вы просто неверно поняли прочитанное. Речь как раз о том, что выбор не стоит между всеми экосистемами systemd и upstart, что значительная часть экосистемы systemd всё равно будет интегрирована, а в качестве init будет использоваться тот, «который нам больше понравится». Где вы здесь увидели, что ему больше нравится upstart, для меня загадка, особенно в свете практически всего остального сообщения, где он утверждает о техническом и архитектурном превосходстве init-компонента systemd.

Как вы вообще для себя объясняете, что человек на несколько экранов расписывает преимущества systemd, а потом вдруг, по-вашему, высказывается о том, что ему больше нравится upstart - вы не замечаете здесь некоторого противоречия? И если да - разве оно не должно было навести вас на сомнения в правильности вашего предположения?

Гы, так вы поймите, это - вынужденный шаг. Какое-то время эти обвязки (удев, логинд) работали (через шим?), но теперь, когда добавились cgroups - работоспособность снова похерилась. Теперь им пришлось переходить на системд-пид1 лишь только чтобы всё снова заработало.

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

udev как работал так и продолжает работать без systemd.

systemd-logind ранее работал без systemd, ибо мог сам управлять своими cgroups, но какое-то время назад разработчики ядра Linux приняли решение о том, что должен быть лишь один процесс, управляющий cgroups, в результате чего systemd-logind больше не мог самостоятельно это делать, поэтому разработчикам systemd пришлось переработать systemd-logind, переложив управление его cgroups на сам systemd init, с которым он общается через шину DBus. systemd-shim - это независимая реализация этих методов DBus, которая перенаправляет их cgmanager. (И тут нужно сказать спасибо разработчикам systemd, которые не стали завязывать systemd-logind на какой-то внутренний интерфейс systemd, а вместо этого использовали DBus-интерфейс, который может быть независимо реализован.) Пока systemd-shim не был готов, Ubuntu использовала старую версию systemd-logind. В новых Ubuntu уже используется новая версия systemd-logind вместе с systemd-shim. systemd как PID 1 ни в одной версии Ubuntu не использовался, во всех им оставался upstart.

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

ага ага :)

тяжелые сервисы и ценные данные на 15.04 :) Ну ну

Сюрприз! systemd уже в 14.10 точно есть (за 14.04 не скажу), просто не используется по умолчанию. Однако никто не мешает установить systemd-sysv или же передать ядру параметр init=/bin/systemd.

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

Где вы здесь увидели, что ему больше нравится upstart, для
меня загадка

Исходное моё сообщение было таким:

Таким образом, он хотел бы видеть вместо системд-пид1 некий другой компонент, но считает, что апстарт пока не доказал, что достоин быть таковым.
Его я и доказывал. Где _вы_ здесь увидели upstart??

udev как работал так и продолжает работать без systemd.

http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI Если и так, то осталось не долго.

В новых Ubuntu уже используется новая версия systemd-logind
вместе с systemd-shim.

Как видите, Марк пишет, что

We’ll certainly complete work to make the new logind work without systemd as pid 1.
Откуда очевидно следует, что сейчас эта работа ещё не завершена. Будь она завершена, стал бы Расс говорить, что disassemble займёт слишком много усилий?

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

Таким образом, он хотел бы видеть вместо системд-пид1 некий другой компонент

Ничего подобного. Повторю ещё раз: учите английский.

Rather, we're talking about _whether_ or not to swap out a core component of
an existing integrated ecosystem with a component that we like better.
«we like better» здесь не утверждается безусловно, а находится под тем же «whether». То есть смысловой пересказ данного предложения таков: «Вместо этого мы обсуждаем, заменять основной компонент уже существующей экосистемы на другой, если он нравится нам больше, или не заменять (если нет)». То есть весь вопрос как раз и состоит в том, какой init-компонент нравится больше, что эквивалентно собственно поставленному выбору systemd vs upstart.

И говорит это всё Расс для того, чтобы сделать вывод, что раз при гипотетическом равенстве systemd init и upstart systemd init выигрывает за счёт отсутствия необходимости в дополнительных работах по интеграции в уже существующую экосистему, то для выбора upstart необходимо показать, что он лучше, чем systemd init - и тогда:

If we do have a reason for doing this, we should seriously consider it.
Всё вышесказанное имеет смысл только в случае равенства upstart и systemd init. Расс же делает, исходя из своих исследований, вывод, что upstart даже близко не равен systemd init. Собственно, всё написано в заключении письма:
4. Conclusion

If I'm correct in my analysis of the community and ecosystem dynamics, I
think upstart needs to show that it is a significantly better technical
choice than systemd in order to warrant the additional project work that
will be required to build on top of upstart.  Given feature parity, I
believe we should adopt systemd so that we can focus our efforts on
interesting new problems rather than on redoing integrations that other
people have already done.

My personal analysis did not show that upstart was significantly better
than systemd, or even at feature parity.  Rather, I believe it is
currently trailing systemd substantially in multiple areas, some of which
will require significant design changes.

Given that, I believe systemd is the clear choice, despite the portability
issues that we will incur by choosing it.
Что тут ещё может быть непонятно?

Откуда очевидно следует, что сейчас эта работа ещё не завершена. Будь она завершена, стал бы Расс говорить, что disassemble займёт слишком много усилий?

Вы на даты вообще смотрите? Эти две записи были написаны ещё когда systemd-shim не был готов, но сейчас это уже не так.

Кроме того, Расс не писал, что disassemble займёт слишком много усилий.

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

Ничего подобного. Повторю ещё раз: учите английский.

До тех пор, пока вы будете выкидывать из моих цитат куски, это не поможет. Так как я буду повторять выкинутое:

Now, I am generally on the side that says loose coupling of ecosystems is
an inherent good.

Эти две записи были написаны ещё когда systemd-shim не был
готов, но сейчас это уже не так.

Пока у них не будет отдельного пакета с логиндом (не только бинарного, но и исходного) - работа не завершена. Насколько я знаю, такого пакета пока нет.

Кроме того, Расс не писал, что disassemble займёт слишком
много усилий.

Подразумевал.

to warrant
going to the effort of disassembling a part of the systemd ecosystem and
swapping in our own component.
Если всё уже сделано, в чём efforts?

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

Мой домашний хост под виртуализацию/сетевое хранилище:

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

aptitude search ~i~nsystemd | awk '{print $2}'
libpam-systemd
libsystemd-daemon0
libsystemd-journal0
libsystemd-login0
systemd-services
systemd-shim

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

До тех пор, пока вы будете выкидывать из моих цитат куски, это не поможет. Так как я буду повторять выкинутое

И что по-вашему означает эта цитата?

Пока у них не будет отдельного пакета с логиндом (не только бинарного, но и исходного) - работа не завершена. 

С какого перепугу? Как паковать systemd, решать его сопровождающим. Достаточно того, что установка пакета systemd не делает его системой инициализации по умолчанию.

Подразумевал.

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

Если всё уже сделано, в чём efforts?

Блин. Да не было ещё на тот момент ничего сделано! На тот момент даже ещё не определились с дальнейшей поддержкой других систем инициализации.

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

И что по-вашему означает эта цитата?

Loose coupling:
Software outside of an init system's implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.

Как я понимаю, в предыдущей цитате Расса имелось в виду, что логинд и прочие сервисы должны быть спортированы на другие инит системы (в тч при помощи шимов) для того, чтобы пакеты, от них зависящие, не зависели бы от системд-пид1. Так бы достигался loose coupling. Однако, он по всему триду пишет свои опасения о том, что такое решение может не появиться. Например, тут: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1729 Вот вы говорите, сейчас уже это всё доделано. А когда именно это произошло? После всех его сообщений, чтоли?

Как паковать systemd, решать его сопровождающим.

Они как раз недавно голосовали на тему того, нужно ли решение о том, чтобы пакеты не имели лишних зависимостей от инит системы. Очень много голосов получил вариант «Support for other init systems is recommended, but not mandatory», но всё-таки, с небольшим отрывом, победил вариант, что решение не требуется. По этому, теперь уже да, решать сопровождающим. А так бы им пришлось делать, чтобы приложения, использующие логинд, зависели бы от пакета с логиндом, но не от всего системд. За этот вариант тоже очень много людей проголосовали, и в обсуждении голосования тоже многие говорили, что пакеты надо отделить. Будут ли это делать в убунте теперь - я не знаю, но раньше такие планы были.

Вот что пишет Расс:

To take the specific example of GNOME, in a world in which there are
multiple implementations of logind that satisfy the same interface, there
is no conflict here.  I want to keep reiterating that, since it seems like
people keep thinking they're at war with others when no actual conflict
exists.  The GNOME maintainers have already said they'd be happy to allow
alternative dependencies, the systemd maintainers have already said they'd
be happy to work with the providers of alternative logind implementations
to sort out the proper dependency and package structure, GNOME upstream
has said that they'd be delighted for such a thing to exist, and everyone
would be happy to have this in place by jessie.  We're all a big happy
family on this point, even if some of the people in the back seat can't
stop poking each other.  :)
Как видите, все хотят альтернативную зависимость по логинду. То есть, это должен быть отдельный пакет.

На тот момент даже ещё не определились с дальнейшей
поддержкой других систем инициализации.

А сейчас какие поддерживать решили? (со ссылкой, если можно)

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

Вот вы говорите, сейчас уже это всё доделано. А когда именно это произошло?

Соответствующий пакет появился в unstable 28 декабря 2013 года.

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

Необязательно отдельный пакет. Главное чтобы установка logind не приводила к смене PID 1 на systemd. Сейчас так и есть: logind входит в пакет systemd, но установка последнего не меняет используемой системы инициализации.

А сейчас какие поддерживать решили? 

Сейчас ввиду решений ТК и исхода GR действует в общих чертах такая схема: пакет обязан поддерживать систему инициализации по умолчанию, но поддержка других систем рекомендуется. См. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715#278.

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

Пульсаудио нельзя сравнивать с осс. Это разные уровни. Пульса использует alsa.

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

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

Алса тоже пыталась в программное микширование, например. Но это не делает её заменой пульсы.

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

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

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

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

Соответствующий пакет появился в unstable 28 декабря
2013 года.

Ну а Расс пишет вот это в марте 2014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#7590

*All* of this argument is over what happens when those multiple
implementations don't actually materialize.
Почему же он столько обсуждает случай, когда loose coupling никто не реализовал, если, по вашему, на тот момент уже всё было доделано?

Да и потом, даже если вы правы, это ж жуткий головняк: поддерживать альтернативный логинд, или шимы, постоянно меняя интерфейсы и оборачивая новый функционал Леннарта, мало кто сможет долго. И что тогда будет с loose coupling?

Необязательно отдельный пакет.

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

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

Да это понятно, но вы скажите, какие конкретно системы инициализации официально будет поддерживать сам дебиан, как дистрибутив. А не «от кого какой пакет зависит».

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

Почему же он столько обсуждает случай, когда loose coupling никто не реализовал, если, по вашему, на тот момент уже всё было доделано?

Потому что в этом сообщении уже идёт абстрактное обсуждение в общем, может ли некоторое ПО зависеть от функций, предоставляемых одной системой инициализации, но отсутствующих в другой, и что в таком случае делать. То есть речь уже не о конкретном logind, а о проблеме в общем.

Да и потом, даже если вы правы, это ж жуткий головняк: поддерживать альтернативный логинд, или шимы, постоянно меняя интерфейсы и оборачивая новый функционал Леннарта, мало кто сможет долго. И что тогда будет с loose coupling?

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

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

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

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

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

Что значит «официально поддерживать»? В зависимости от ответа смотрите в Политику Debian или в список пакетов.

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

Где код?

Беспомощность то какая, даже исходники найти проблема. Даете команду

git clone git://anongit.freedesktop.org/systemd/systemd
Команду нужно давать из каталога в который можете писать, иначе ничего не получится. Далее смотрите исходники в src/firstboot/firstboot.c

Если команда git не найдена значит ее нужно установить.

так и не предложил, не требующих рута реализаций перехвата паролей

Читать до просветления: http://en.wikipedia.org/wiki/Unix_signal

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

Тебе 12 лет? Ты не видал, что происходит, если в проекте долгое время лежит своя, пахнущая малиной, реализация некоторой фичи?

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