Статус

Все фичи, обозначенные выше уже реализованы. Прямо сейчас systemd может использоваться как временная замена Upstart и sysinit (по крайней мере до тех пор пока нету так много нативно реализованных сервисов upstart. Слава богу большинство дистрибутивов не сильно переживают о реализации нативных сервисов upstart, пока что.)

Тем не менее, тестирования systemd было минимальным, текущий номер версии впечатляющий 0. Ожидайте аварийное поведение если вы запустите systemd в текущем его состоянии. (прим. переводчика, имеется в виду на момент написаний оригинальной статьи — 2010 год). Как бы сказано, в целом он должен быть вполне стабильным и некоторые из нас уже запускают свои рабочие системы с помощью systemd (в контраст к запуска на только на виртуальных машинах). Ваше мнение может отличаться, особенно если вы используете дистрибутив отличный от используемых нашими разработчиками.

Куда все двигается?

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

Мы хотим добавить как минимум еще два типа юнитов: swap который будет управлять swap устройствами в той же манере как мы уже управляем точками монтирования, например, автоматические зависимости на дерево устройств с которых запускаются и так далее. timer должен предоставлять функциональность похожую на cron, например, запускать службы на основе событий часов, фокусировка на событиях от монтонных часов и реальных часов/календаря. (например, «запустить это через 5 часов после последнего запуска» также как «запускать это каждый понедельник в 5 утра»)

Наиболее важное тем не менее, это также наши планы по экспериментированию с systemd не только для оптимизации времени загрузки, но также сделать его идеальной менеджером сессий, чтобы заменить (или возможно обобщить) gnome-session, kdeinit и подобные службы. Набор проблем менеджера сессий и системы загрузки очень похожи между собой: быстрый запуск в основе и процесс «сиделка» в фокусе. Использование кода в обоих случаях рекомендует себя само. Apple признало это и сделало это с launchd. Также должны и мы: сокет и шина-основанные активация и параллелизм это нечто, от чего службы сессии и системные службы могут получить преимущество в равной мере.

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

Тем не менее, существуют вещи, которые вероятно должны быть исправлены в ядре и где-нибудь еще перед окончанием работ: нам необходимы оповещения об изменении статуса swap от ядра, наподобие того как мы уже подписываемся на изменения в точках монтирования; нам необходимы оповещения когда CLOCK_REALTIME скачет относительно к CLOCK_MONOTONIC; мы хотим позволить нормальным процессам получить некоторую init-подобную «силу»; нам необходимо четко определенное место где мы можем хранить пользовательские сокеты. Ни один из этих проблем не является существенным для systemd, но решение из в целом бы улучшило положение вещей.

Хотите увидеть все это в действии?

На данный момент, мы не предоставляем тарбольных релизов, но должно быть довольно просто вытянуть код с репозитория. В дополнение, чтобы было с чего начать, здесь лежит тарбол с конфигурационными юнит файлами, который позволит не модифицированную системы с Fedora 13 работать с systemd. И на данный момент мы не можем вам предложить RPM пакетов.

Самый простой способ — это загрузить образ qemu с Fedora 13, который был подготовлен для systemd. В меню grub вы сможете выбрать: загрузиться с systemd или с Upstart. Заметьте, что это система минимально модифицирована. Служебная информация считывается с эксклюзивно из существующих SysV скриптов. Таким образом, система не будет преимуществ предоставляемых полного сокет и шина-основанного параллелизма, обозначенной выше, тем не менее он будет интерпретировать отметки параллелизма из LSB заголовков, и следовательно будет грузиться быстрее чем Upstart, который в данный момент в Fedora не предоставляет никакого параллелизма. Этот образ сконфигурирован выводить отладочную информацию на консоль, так же как запись в лог ядра (который может быть получен просмотрен через dmesg). Вы можете запустить qemu с конфигурированной виртуальным терминалом. Все пароли выставлены в systemd.

Даже проще чем загрузка и запуска qemu образа — это посмотреть на приятные скриншоты. Так как система загрузки как обычно хорошо спрятана под пользовательским интерфейсом, предоставляю некоторые скриншоты systemdadm и ps:

На этом скрине systemadm показывает все загруженные юниты, с более детальной информацией на одно из экземпляров getty.

На этом рисунке показаны выдержка из вывода команды ps xaf -eo pid,user,args,cgroup показывая как аккуратно процессы отсортированы в cgroup своих служб. (Четвертая колонка — это cgroup, префикс debug: показан потому что мы используем отладочный cgroup контроллер для systemd, как мы заметили ранее. Это временно!)

Прошу заметить что оба этих скриншота показаны на минимально модифицированной Live CD Fedora 13, где сервисы эксклюзивно загружены с существующих SysV скриптов загрузки. Следовательно, эта система не использует сокет или шина-основанную активацию для существующих сервисов.

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

Такс, вероятно все будут приставать ко мне по поводу этого, но есть два числа, о которых я вам должен поведать. Несмотря на то, что они полностью научно не обоснованные так как они замерены на виртуальной машине (с одним CPU) и используя секундомер в моих часах. Fedora 13 грузится с Upstart 27 секунд, с systemd 24 секунды (c grub до gdm, одна и та же систем, с теми настройками, с минимальным временем между загрузками, друг за другом). Тем не менее, заметьте что это показывает на ничто иное как ускорение скорости загрузки благодаря использованию LSB зависимостей, спрасеных из заголовков скриптов загрузки для распараллеливания. Сокет и шина основанная активация не использовалась для этих измерений, и следовательно эти числа являются не подходящими для оценки идей изложенных выше. Так что повторюсь, данные этих измерений могут быть любыми другими числами.

Пишем демоны

Идеальный демон для использования с systemd должен делать немного различные вещи нежели традиционные демоны. Чуть позже, мы опубликуем длинное руководство объясняющее и предлагающее как писать демоны для использования с systemd. В общем, вещи стали проще для разработчиков демонов:

• Мы просим разработчиков демонов не форкаться или даже вдвойне форкаться в своих процессах, но запускать свой поток обработки из исходного процесса, а все остальное за вас сделает systemd. Также не вызывайте setsid().
• Не скидывайте права пользователя в самом демоне, оставьте это для systemd и настройке права в конфигурационном файле службы. (Здесь есть исключения. Для примера, для некоторых демонов есть веские причины сбросить привелегии внутри кода демона, после фазы инициализации и запросить повышение привилегий.
• Не создавайте PID файлы
• Получите имя на шине
• Вы можете переложить логгирование на systemd, все, что вы хотите внести в журнал просто пишите это в stderr.
• Позвольте systemd создавать и наблюдать за сокетами за вас, так что будет работать активация на основе сокетов. Следовательно, используйте $LISTEN_FDS и $LISTEN_PID как описано выше.
• Используйте SIGTERM для остановки ваших демонов (служб).

Список выше очень похож на что Apple рекомендует для совместимости демонов с launchd. Должно быть легко расширить демоны, которые уже поддерживают активацию через launchd также для поддержки активации через systemd.

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

Так что да, systemd должен показать себя в наших экспериментах и быть адаптированным дистрибутивами; было бы хорошо начать с сервисов, которые запускаются по умолчанию, чтобы они использовали сокет или основанную на шине активацию. Мы написали серию патчей proof-of-concept чтобы портирование стало очень простым. Также, мы должны применять работу, которая уже сделана для launchd, до определенной степени. Более того, добавляя поддержку для активации служб по сокету не делает ее не совместимой с systemd.

ЧаВо

Кто стоит за этим?

Итак, текущая кодовая база по большей части моя работа, Леннарт Поетеринг (Red Hat). Тем не менее, архитектура во всех деталях — это результат взаимодействия с Кейм Сиверсом (Novell). Были вовлечены и другие люди Гарольд Хойер (Red Hat), Давал Джиани (был в IBM), и несколько других ребят из Intel, SUSE и Nokia.

Это проект RedHat?

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

Придет ли это в Fedora?

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

Придет ли это в OpenSUSE?

Кей преследует эту цель, так что, что применяется для Fedora, верно и для него.

Придет ли это в Debian/Gentoo/Mandriva/MeGoo/Ubuntu/[вставьте сюда еще Ваш любимый дистрибутив]?

Все на их совести. Мы определенно будем приветствовать их интерес, и поможем с интеграцией.

Почему вы просто не добавили это в Upstart, почему вы изобрели велосипед?

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

Если вы так любите launchd от Apple, почему бы просто не адаптировать его?

launchd — это отлично изобретение, но я не убежден, что он хорошо впишется в Linux, не из-за того, что он не предназначен для Linux с огромной масштабируемостью и гибкостью для различных целей и применения.

Это проект NIH?

Надеюсь, я попытался объяснит в тексте выше почему мы пришли к новому решению, вместо постройки на основе Upstart или launchd. Мы пришли к systemd в следствие технических, а не политических причин. Не забывайте, что Upstart включает в себя библиотеку названную NIH (который в некотором роде является реализацией glib).

Будет ли это работать на [вставьте сюда не Linux ОС]?

Навряд Ли! Как было замечено, systemd использует много специфичного Linux API (такие как epoll, signalfd, libudev, cgroups, и еще несколько) портирования на другие операционные системы выглядит для нас затей не особо имеющим смысла. Также, мы — люди вовлеченные, не особо заинтересованы в слиянии возможных портов в другие платформы и работать с возможным ограничениями, которые они принесут в систему. И все таки, git поддерживает ветвление и rebase вполне хорошо, в случае кто-то действительно захочет сделать порт.
На самом деле переносимость еще более ограничена, чем просто переносом на другие ОС: мы зависим от очень свежего ядра Linux, glibc, libcgroup и libudev. Не поддерживаем менее чем текущие Linux системы, простите.
Если ребята хотят реализовать что-то похожее для других операционных систем, предпочитаемый способ взаимодействия вероятнее мы поможем определить какие интерфейсы могут быть разделены с вашей системой, чтобы сделать жизнь проще для писателей демонов, в поддержке обоих systemd и вашего порта. Вероятно, фокус должен быть направлена на разделение интерфейсов, а не кода.

Я слышал [введите один здесь: система загрузки Gentoo, initng, Solaris SMF, runit, uxlaunch, ...] отпадная система загрузки и также может делать параллельную загрузку, так почему бы не адаптировать его?

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

Контрибы

Мы очень заинтересованы в патчах и помощи. Это должно быть общим ощущением, что любой Бесплатный Софт (Free Software) может получать пользу только через широчайшие внешние контрибы. Это, в частности, справедливо для ключевой части ОС, такой как система загрузки. Мы ценим ваши контрибы (вклад в проект) и следовательно не присваиваем себе авторские права. (Очень не похоже на то, что делает Canonical/Upstart!). А также, мы используем всеми любимый Git, ура!

В частности мы заинтересованы в помощи, чтобы systemd начал работать и на других дистрибутивах, кроме Fedora и OpenSUSE. (Эй, кто-нибудь из Debian, Gentoo, Mandriva и MeeGo ищете что-нибудь поделать?). Более того, мы встаем на колени, чтобы привлечь внимание контрибьюторов на каждом уровне: мы приветствуем С хакеров, сборщиков пакетов, также как ребят заинтересованных в написании документации, или кто хочет предоставить лого.

Сообщество

На данный момент (прим. переводчика 2010 год) у нас есть только Git репозиторий и IRC канал (#systemd на freenode). Нет списка рассылки, веб-сайта или системы баг трекинга. Мы вероятно добавим что-то на freedesktop.org. Если у вас есть какие-либо вопросы или вы хотите связаться с нами, в любом случае мы призываем вас присоединиться к нам в IRC!