Система инициализации Systemd. Часть II

Это продолжение начатого тут.

Собираем все вместе - systemd

Выше я объяснил, что должен делать хороший процесс с PID 1 и как работают существующие системы инициализации. Перед тем как перейти к самому главному, давайте сделаем еще паузу. Сходите налейте себе еще кружечку кофе. Это того стоит.

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

Поскольку systemd запускает и контролирует всю систему, отсюда и ее название. Она реализует все возможности, указанные выше, и еще кое-что. Система построена на концепции модулей (units). Модули имеют имя и тип. Поскольку их конфигурация обычно загружается из файловой системы - названия модулей на самом деле представляют собой имена файлов. Например: модуль avahi.service считывается из конфигурационного файла с тем же именем и естественно, что он реализует работу с демоном Avahi. Существует несколько видов модулей: 

• service/сервис: наиболее очевидный тип модуля: это демоны, которые могут быть запущены, остановлены, перезапущены или перезагружены. Для совместимости с SysV в systemd помимо собственных файлов конфигурации для различных сервисов имеется возможность чтения классических скриптов инициализации SysV, а также она умеет разбирать заголовок LSB, если он существует. /etc/init.d является, следовательно, не более, чем просто еще одним источником конфигурации.

• socket/сокет: данный модуль реализует сокет, расположенный в файловой системе или в Интернете. В настоящее время поддерживаются сокеты AF_INET, AF_INET6, AF_UNIX типов stream, datagram и последовательных пакетов (sequential packet). Также поддерживаются классические буферы FIFO. Каждый модуль типа «сокет» имеет соответствующий ему модуль «сервис», который запускается при попытке установки соединения с сокетом или буфером FIFO. Пример: nscd.socket при установке соединения запускает nscd.service.  
• device/устройство: этот модуль реализует устройство в дереве устройств Linux. Если устройство описано через правила udev, оно будет представлено в systemd как модуль устройство. Набор параметров устройства, установленный udev, будет использоваться systemd как исходный в определении зависимостей для этого типа модулей. 
• mount/точка монтирования: модуль реализует точку монтирования в файловой системе. systemd контролирует все точки монтирования (их подключение и отключение), а также может быть использована для монтирования и размонтирования отдельных файловых систем. Файл /etc/fstab используется как дополнительный источник конфигурации для них, подобно тому, как сценарии инициализации SysV могут быть использованы в качестве дополнительного источника конфигурации для модулей service. 
• automount/точка монтирования с автоматическим подключением: модуль реализует точку монтирования с автоматическим подключением файловой системы. Каждый такой модуль имеет соответствующий ему модуль типа mount, который запускается (т.е. подключается), как только монтируемая файловая система становится доступной. 
• target/указатель: данный тип модулей используется для логической группировки других модулей: на самом деле сам по себе он ничего не делает, он просто указывает на другие модули, которыми таким способом можно управлять вместе. В качестве примера можно привести модули multi-user.target, который играет роль 5-го уровня запуска в классической схеме SysV, и bluetooth.target, активируемый, как только становится доступен Bluetooth-адаптер, и запускающий сервисы, имеющие отношение к Bluetooth (которые обычно не запущены - bluetoothd и obexd) (т. е. по сути это придет на смену традиционным уровням запуска SysV - прим. перев.). 
• snapshot/снимок: подобно предыдущему типу модулей снимки также ничего не делают сами, и их единственное преданзначение заключается в ссылке на другие модули. Снимки могут быть использованы для сохранения состояния и возможности отката назад состояния всех служб и модулей системы инициализации. Он, главным образом, предназначен для двух случаев. Первый, чтобы позволить пользователю временно перевести систему в какое-то специфичное состояние, например, однопользовательский режим с остановкой всех работающих сервисов, а затем легко вернуться в предыдущее состояние с одновременным запуском тех сервисов, которые были перед этим запущены. Второй вариант его использования - поддержка режима suspend: достаточно много сервисов не могут корректно работать с этой системой, и зачастую их лучше остановить перед засыпанием, а потом просто запустить.

Приведенные модули могут иметь зависимости друг от друга (как положительные, так и отрицательные, т. е. бывает, что одни без других не могут обойтись, а другие, наоборот, не могут терпеть друг друга): например, модуль устройство может зависеть от какого-то модуля сервис, т.е. как только устройство становится доступным - запускается определенный сервис. Модули mount имеют неявную зависимость от устройства, которое они пытаются смонтировать. Также они наследуют неявные зависимости от префиксов путей к точкам монтирования (например, модуль, подключающий /home/lennart, неявно зависит от модуля, подключающего /home)и так далее.

Краткий перечень остальных функциональных возможностей:

1. Для каждого порожденного процесса вы можете контролировать: среду исполнения, ограничения ресурсов, рабочую и корневую директории, umask, настройки OOM killer, параметр nice, класс и приоритет операций ввода-вывода, политику и приоритеты использования процессора, привязку к процессору, таймер, идентификаторы пользователя, основной и дополнительных групп, списки директорий, доступных для чтения/записи, список директорий, доступ к которым запрещен, флаги монтирования, биты безопасности, параметры, относящиеся к планировщику процессора CPU, области видимости /tmp, привязку к cgroup для различных подсистем. Также можно присоединить stdin/stdout/stderr сервисов к syslog, /dev/kmsg, произвольным TTY. Если вы присоединяете TTY ко входу systemd - удостоверьтесь в том, что процесс получает эксклюзивный доступ. 
2. Каждый запущенный процесс получает собственную cgroup (в текущем состоянии разработки по умолчанию они создаются в подсистеме debug, поскольку она все равно не используется). С помощью systemd также легко помещать отдельные сервисы в различные cgroups, причем, это можно сделать из пользовательского пространства, например, посредством утилит libcgroups. 
3. Файлы конфигурации systemd имеют синтаксис, аналогичный используемому в файлах .desktop, который прекрасно разбирается (parse) многими имеющимися утилитами и имеет все необходимое для интернационализации. Поэтому администраторам и разработчикам не нужно учить новый синтаксис. 
4. Как упоминалось выше, мы (Здесь и далее под "мы" понимаются разработчики и сама systemd, надо смотреть по контексту. Обычно это нормально, когда автор осознает свое единство со своим творением :). Список основных разработчиков приведен в конце этой статьи. Прим. перев.) обеспечиваем совместимость со скриптами SysV, дополнительно к этому обрабатываются заголовки LSB и утилиты chkconfig RedHat. Если их нет, просто используется любая доступная информация (такая, как приоритеты запуска сервисов) из /etc/rc.d. Поскольку эти скрипты начинают просто читать другой источник конфигурации, обновиться с SysV на systemd достаточно легко. Дополнительно мы можем читать классические PID-файлы сервисов, чтобы определить PID главного демона. Также мы можем использовать информацию о зависимостях из LSB-заголовка скрипта и транслировать ее в «родной» формат описания зависимостей для systemd. Важное замечание: Upstart не может использовать эту информацию. Во время запуска Upstart, в отличие от systemd, не распараллеливает запуск большей части скриптов LSB и/или SysV. Фактически, для Upstart все скрипты SysV - это одно исполняемое задание (Тут опять автор немного лукавит. В Upstart просто оставлен слой совместимости со скриптами SysV, который действительно работает, как описано. Но это именно что слой совместимости с теми службами, управляющие скрипты которых по каким-то причинам пока не отконвертированы в "родной" формат для Upstart, а не "злостная недоработка" разработчиков Upstart. Прим. перев.).
5. Аналогичным образом, существующий файл /etc/fstab читается и используется как еще один источник конфигурации. А с использованием опции comment= fstab вы даже можете отметить отдельные записи в этом файле, чтобы передать их под контроль systemd (для обеспечения работы функционала автоматического монтирования). 
6. Если для одного сервиса существует несколько файлов конфигурации (например, есть два файла /etc/systemd/system/avahi.service и /etc/init.d/avahi), тогда "родной" формат файлов имеет преимущество. Устаревший формат файлов игнорируется, позволяя легко провести обновление. 
7. Мы также поддерживаем механизм использования шаблонов. Например, вместо того, чтобы иметь шесть одинаковых конфигурационных файлов для шести getty, у нас есть только один файл getty@.service, который используется сервисом getty@tty2.service и аналогичными ему. Интерфейсная часть также может наследоваться выражениями, описывающими зависимости, т. е. легко понять, что сервис dhcpcd@eth0.service запускается сервисом avahi-autoipd@eth0.service. 
8. Для активации сервисов посредством сокетов, мы поддерживаем полную совместимость с традиционной моделью inetd, а также простой режим, имитирующий работу launchd, который рекомендуется к использованию для вновь создаваемых сервисов. Режим совместимости с inetd позволяет передавать запускаемому демону только один сокет, в то время как "родной" режим работы позволяет передавать произвольное количество дескрипторов файлов. Мы поддерживаем как режим с одним экземпляром сервиса на одно соединение, так и с одним экземпляром на все соединения. Например: sshd.socket может запускать сервис sshd@192.168.0.1-4711-192.168.0.2-22.service с cgroup sshd@.service/192.168.0.1-4711-192.168.0.2-22 (т. е. IP-адрес и номера портов используются в качестве имен). Для сокетов AF_UNIX, используется PID и идентификатор пользователя присоединяющегося клиента. Это предоставляет администратору прекрасный инструмент для определения различных экземпляров одного и того же демона и контроля за ним. «Родной режим» передачи сокета легко реализовать в приложениях: переменная $LISTEN_FDS, если она установлена, содержит количество передаваемых сокетов, и демон может найти их в файле .service, начиная с файлового дескриптора 3 (хорошо написанный демон также может использовать fstat() и getsockname() для идентификации сокетов в случае, если их больше одного). В дополнение мы устанавливаем переменную $LISTEN_PID, содержащую PID главного демона, который получает сокеты, потому что переменные среды обычно наследуются дочерними процессами, что может несколько запутать процессы, находящиеся далее в цепочке. Поскольку логика передачи сокетов очень проста, мы предоставляем примерную реализацию этого процесса под лицензией BSD. Также мы портировали множество существующих демонов на эту схему. 
9. Мы предоставляем совместимость с интерфейсом /dev/initctl. Эта совместимость фактически реализована с помощью сервиса, активируемого посредством FIFO, который просто транслирует устаревшие запросы в запросы D-Bus. На практике это означает, что старые команды shutdown , poweroff и аналогичные им из Upstart и sysvinit будут работать с systemd. 
10. Мы предоставляем совместимость с utmp и wtmp. Код, который это делает, выглядит гораздо более жизнеспособным, чем эти файлы :).
11. systemd поддерживает несколько типов зависимостей между модулями. After/Before могут использоваться для определения последовательности запуска. Requires/Wants определяет статус зависимости, является она обязательной или опциональной. И наконец, Conflicts определяет отрицательный характер зависимости (т. е. две и более службы, у которых в зависимостях указана Conflicts, не смогут быть запущены одновременно - прим. перев.). Есть также еще три, менее часто используемые типы-зависимостей. 
12. systemd построена как система с минимумом транзакций. Это означает: если модуль запросил запуск или остановку, мы добавляем его и все его зависимости во временную транзакцию. Затем проверяем целостность этой транзакции, т.е. последовательности обработки зависимостей After/Before для всех модулей на возможность появления циклических зависимостей. Если они есть, systemd пытается исправить ситуацию путем удаления из транзакции «несущественных» (non-essential) заданий. Также systemd пытается убрать из транзакции такие из «несущественных» заданий, которые могут остановить какой-либо другой сервис (не имеющий отношение к останавливаемому модулю). «Несущественными» являются такие задания, которые не относятся к оригинальному запросу, но при этом помещены в очередь на основе зависимостей Wants. В заключение проверяется, могут ли задания в транзакции противоречить заданиям, которые уже находятся в очереди и, если возникла такая ситуация, транзакция отменяется. Если все сработало корректно, транзакция целостна и минимизирована по количеству операций, она ставится в очередь на исполнение. В сухом остатке это означает, что перед запуском запрошенной операции мы проверяем, имеет ли смысл ее вообще выполнять, если возможно, исправляем возникшие ошибки, и затем ничего не делаем, если операцию выполнить невозможно. 
13. Мы записываем время запуска/остановки, PID и статус завершения для каждого из порождаемых и/или контроллируемых процессов. Эти данные позволяют увязать демоны с их данными в abrtd, auditd и syslog и создать интерфейс, который выделял бы упавшие демоны и предоставлял бы всю необходимую о них информацию.
14. Мы также реализовали самостоятельный перезапуск процесса init в любое время по требованию. Состояние демона замораживается перед этим и размораживается после. Таким образом мы упрощаем онлайнового обновления с SysV init на systemd, а также передачу полномочий от остановленного к перезапущенному демону. Запросы к открытым сокетам и точкам монтирования autofs, как уже отмечалось выше, будут корректно упорядочены и поставлены в очередь ядром, поэтому клиенты даже не почувствуют, что что-то вообще произошло. Поскольку большая часть информации о состоянии обслуживаемых systemd процессов хранится в виртуальной файловой системе cgroup, это позволяет нам не прерывать их исполнения из-за невозможности доступа к данным init. Код, реализующий перечитывание конфигурации init, является общим с кодом его перезапуска. 
15. Избавляясь от shell-скриптов в процессе запуска системы, мы переписали основную их часть на C и поместили непосредственно в systemd. В частности, это код таких операций как монтирование виртуальных файловых систем /proc, /sys and /dev и установка имени хоста. 
16. Состояние сервиса доступно и может контроллироваться через D-Bus (за это Upstart не пинал только самый ленивый - прим. перев.). Правда, эта возможность пока не реализована и находится в стадии активной разработки. 
17. Мы придаем особое значение активации сервисов посредством сокетов либо через D-Bus (и, следовательно, поддерживаем обработку соответсвующих зависимостей). В то же время мы поддерживаем традиционные зависимости только между сервисами. Также поддерживается несколько способов, которыми сервис может сообщить о своей готовности: путем вызова fork() и завершением родительского процесса (традиционное поведение daemonize()) и посредством публикации своего имени на D-Bus.
18. Существует интерактивный режим, который запрашивает подтверждения для каждого из процессов, порождаемого systemd. Вы можете включить это, передав параметр systemd.confirm_spawn=1 в строке параметров ядра.
19. С помощью параметра systemd.default= в строке параметров ядра вы можете указывать, какой из модулей systemd нужно запускать при загрузке системы. Обычно здесь находится что-то вроде multi-user.target, но можно указать и какой-то один сервис вместо модулей типа «указатель», к примеру, «из коробки» мы поставляем сервис emergency.service, который по своему назначению подобен параметру init=/bin/bash, но по сравнению с ним имеет то преимущество, что можно запустить полнофункциональную систему прямо из оболочки восстановления от сбоев (emergency shell). 
20. Также есть минимальный пользовательский интерфейс, позволяющий запускать/останавливать сервисы и наблюдать за ними. Правда, он еще далек от завершения, но вполне может использоваться как утилита для поиска ошибок. Он написан на Vala и называется systemadm.

Следует также заметить, что systemd использует много специфичных для Linux возможностей, не ограничиваясь стандартами POSIX. Это позволяет использовать огромное количество возможностей Linux, разработанных для портируемости, которые остальные системы не предоставляют.

Состояние разработки

Значительная часть перечисленных выше возможности уже реализована. В настоящее время systemd уже может использоваться как полноценная замена для Upstart и sysvinit (по крайней мере, пока не все сервисы еще отконвертированы в формат Upstart, за что спасибо разработчикам основных дистрибутивов).

Однако объем тестирования systemd минимальный, поэтому номер версии, которую мы имеем на сегодняшний день - это абсолютный и великолепный НОЛЬ. Так что, если решитесь использовать ее в таком виде, как она есть, ждите появления некоторого количества неожиданных проблем (автор намекает на необходимость обязательного наличия бубна при использовании systemd на рабочих машинах - прим. перев.). Другими словами, все должно работать почти стабильно. Кое-кто из нас был настолько смел, что загружал наши рабочие машины с помощью systemd (не только виртуальные, но и те, которые мы обычно используем для разработки). В общем, тут как повезет, особенно если пробовать systemd на дистрибутивах, которые мы - разработчики - не используем.

Предполагаемые направления развития

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

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

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

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

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

Вы хотите увидеть systemd в действии?

Мы пока еще не выпускали релизов, поэтому у нас нет готовых тарболов. Но если вам очень хочется, вы всегда можете сделать снимок с нашего текущего репозитория (git). В дополнение, чтобы вы вообще могли что либо запустить, здесь можно скачать тарбол с конфигурационными файлами для модулей, которые позволяют немодифицированной Fedora13 работать с systemd. У нас пока нет готовых RPM, чтобы их предложить вам.

Самый легкий путь - это скачать этот образ Fedora 13 для qemu, который специально приготовлен для systemd. В меню grub вы сможете выбрать - будете ли вы грузиться с помощью Upstart или с помощью systemd. Эта система имеет минимальный набор модификаций. Информация о сервисах читается исключительно из существующих скриптов SysV. «Благодаря» этому мы не получаем всех преимуществ от активации сервисов посредством сокетов и D-Bus. Но особенности systemd позволяют параллелизовать запуск сервисов только на основе чтения заголовков LSB и уже только это позволяет нам грузиться быстрее, чем через Upstart. Образ сконфигурирован таким образом, чтобы выдавать информацию для отладки на последовательную консоль и в буфер ядра для ведения логов (просматриваемый с помощью dmesg). Поэтому необходимо сконфигурировать для qemu поддержку виртуального последовательного терминала. В качестве всех паролей установлен systemd.

Еще более простой путь - это посмотреть на эти прекрасные скриншоты. На первом приведен интерфейс утилиты systemadm:

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

Это вывод команды ps xaf -eo pid,user,args,cgroup, показывающей насколько аккуратно все процессы отсортированы по своим cgroups (Это показывает четвертая колонка с префиксом debug: такой префикс используется по той причине, что мы пока используем специальный контроллер cgroup для отладки. Это описывалось выше.)

К сожалению, у нас пока еще нет графиков загрузки или еще каких-то данных по времени запуска системы. Мы их опубликуем, как только сможем полностью параллелизовать запуск всех сервисов, поставляемых в Fedora. В тоже время, мы приветствуем проведение ваших собственных тестов и публикацию их результатов.

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

Написание демонов

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

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

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

Часто задаваемые вопросы

Кто основные разработчики?

Большая часть кодовой базы - моя собственная работа, Lennart Poettering (Red Hat). Однако, общий дизайн и его отдельные детали - это результат моего взаимодействия с Kay Sievers (Novell). Также в проекте участвуют Harald Hoyer (Red Hat), Dhaval Giani (бывший сотрудник IBM), и многие другие из таких компаний как Intel, SUSE and Nokia.

 

Это проект Red Hat?

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

 

Увидим ли мы это в Fedora?

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

 

Увидим ли мы это в OpenSUSE?

Этим занимается Kay, но думаю, что все будет также же, как и в Fedora.

 

Увидим ли мы это в Debian/Gentoo/Mandriva/MeeGo/Ubuntu/[Моем_любимом_дистрибутиве]?

Это вопрос к их разработчикам. Мы можем только приветствовать их интерес и помочь с интеграцией.

 

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

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

 

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

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

Это проект NIH?

(Тонкий укол, намекающий на то, что разработчики пошли по собственному пути только по причине того, чтобы начать свой собственный проект. Проект ради проекта. Прим. перев.)

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

 

Будет ли systemd работать на [моей_любимой_операционной_системе_отличной_от_ Linux]?

Маловероятно. Выше мы отметили systemd использует много специфичных для Linux API (таких как as epoll, signalfd, libudev, cgroups и т.п.), поэтому портирование его на другую операционную систему выглядит (по нашему мнению), как не стоящий своих затрат. Мы, разработчики проекта, не заинтересованы в работе, предполагающей портирование на другие платформы. Для тех, кто заинтересован в этом, мы можем только сказать, что git хорошо поддерживает концепцию ветвей (branches).

Скажу больше, портируемость ограничивается не только окружением, в котором работает systemd: нам нужны самые последние версии ядра Linux, glibc, libcgroup и libudev.

Если кто-либо хочет сделать нечто подобное для других операционных систем, можем предложить приемлемый режим взаимодействия: мы поможем вам определить какие интерфейсы являются общими с вашей системой, сделаем немножко легче жизнь тех, кто будет писать демоны для systemd и ее аналога. Мы можем помочь идеями, но не кодом.    

 

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

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

Помощь проекту 

 

Мы очень заинтересованы в патчах и другой помощи. В этом смысле наш проект ничем не отличается от любых других проектов свободного ПО, основные преимущества которых заключаются в как можно более широком взаимодействии с сообществом. И это, действительно, большей частью правда для такой фундаментальной части системы, как система инициализации. Нам ценно взаимодействие с вам, поэтому мы не требуем передачи прав (в отличие от Canonical/Upstart!). Мы также используем git, как всеми любимую систему контроля версий!

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

Сообщество 

 

В настоящее время, все что у нас есть - это репозиторий с исходным кодом и IRC-канал (#systemd на Freenode). Нет списков рассылки, веб-сайта или системы отслеживания ошибок. Возможно, что скоро у нас будет нечто подобное на freedesktop.org. Если у вас есть некоторые вопрос, которые вы хотите задать нам, мы приглашаем вас к нам на IRC-канал!

Оригинал статьи на английском