LXF143:DrBrown3
|
|
|
Содержание |
Реформы процесса загрузки
- Пока борются титаны загрузки, доктор изучает отважного новичка.
В старые добрые времена процесс загрузки Unix BSD был доступен пониманию. Систему можно было запустить в однопользовательском режиме, и вы попадали в консоль пользователя root, или в многопользовательском режиме. Затем появилась System V с ее уровнями выполнения – одно из первых заболеваний типа «а добавим-ка на один уровень сложности больше, чем нужно». Тем не менее, люди привыкли к причудам файла inittab, символическим ссылкам S* и K* и перечню зависимостей в виде комментариев в скриптах запуска системы.
Затем появился Upstart. Я уже брюзжал, что происходящее в этой управляемой событиями системе трудно понять (LXF129). А теперь все изменится благодаря systemd, детищу умов Леннарта Поттеринга [Lennart Poettering] и Кая Сиверса [Kay Sievers]. Поясняю: это systemd, а не System D. Не было никаких систем A, B и C; это системный демон.
Цитирую страницу проекта: «Systemd – это системный менеджер и менеджер сервисов для Linux, совместимый с SysV и скриптами запуска LSB». Systemd предоставляет интенсивные возможности распараллеливания, запускает сервисы через активацию D-BUS и сокеты и демонов по требованию, отслеживает процессы с помощью cgroups, позволяет делать снимки состояния системы и восстанавливать по ним это состояние, поддерживает точки монтирования и автомонтирования и реализует тщательно проработанную транзакционную логику управления сервисами на основе зависимостей.
Раздувание процессами
В своем блоге (http://0pointer.de/blog) Леннарт приводит убедительный довод против «заражения процесса загрузки скриптами», указывая, что традиционные скрипты запуска System V часто вызывают awk, sed или grep для выполнения относительно простых операций. И каждый такой вызов означает создание нового процесса. Попробуйте сразу после загрузки открыть терминал и набрать следующую команду:
echo $$
Она даст вам представление о количестве процессов, перемалываемых системой при загрузке. У меня результаты были такими: в Fedora 14 и Ubuntu 10.10 (обе системы применяют Upstart) обнаружилось 1772 и 1611 процессов соответственно; в Red Hat Enterprise Linux (RHEL) 5 с традиционной SysV – аж 6781. Systemd может исключить многие из этих скриптов и распараллелить процесс загрузки, существенно ее ускорив.
Systemd изначально предназначалась для Fedora 14, но затем было решено отложить ее выход до Fedora 15, где она будет использоваться по умолчанию. Желая набраться опыта работы с systemd, я установил Rawhide, свежую рабочую версию Fedora. Так я получил доступ к рабочей версии системы и связанным с ней командам и man-страницам.
Главная утилита администрирования – systemctl. Без параметров она выводит список активных модулей, которыми управляет systemd:
$ systemctl UNIT LOAD ACTIVE SUB JOB DESCRIPTION sys-devi…ty-tty2.device loaded active plugged /sys/devices/virtual/tty/tty2 dev-mqueue.automount loaded active running POSIX Message Queue File System Automount Point home.mount loaded active mounted /home udev.service loaded active running udev Kernel Device Manager systemd-logger.socket loaded active running Logging Socket cryptsetup.target loaded active active Encrypted Volumes systemd-…es-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
Я сильно сократил этот вывод, оставив по примеру для каждого из типов модулей, которыми управляет systemd. Они включают:
- device Устройство в дереве устройств Linux
- automount Точка автомонтирования файловой системы. У каждого модуля есть соответствующий модуль mount.
- mount Точка монтирования файловой системы.
- service Демоны, которых можно запускать, останавливать, перезапускать, перегружать.
- socket Сокет интернет-домена или Unix-домена. У каждого модуля есть соответствующий модуль service.
- target Логическая группа модулей (цель), аналогичная «метапакету» в управлении пакетами.
- timer Модули этого типа активируют другие модули по таймеру.
- snapshot Цель, которая сохраняет текущее состояние сервисов, чтобы позже его можно было восстановить.
- path Активация других модулей на основе существования файла или создание файла.
Более подробную информацию о модуле можно получить таким образом:
$ systemctl status udev.service udev.service - udev Kernel Device Manager Loaded: loaded (/lib/systemd/system/udev.service) Active: active (running) since Tue, 04 Jan 2011 09:00:48 -0500; 6h ago Process: 459 (/sbin/udevadm trigger --type=devices --action=add, code=exited, status=0/SUCCESS) Process: 443 (/sbin/udevadm trigger --type=subsystems --action=add, code=exited, status=0/SUCCESS) Main PID: 410 (udevd) CGroup: name=systemd:/system/udev.service ├ 410 /sbin/udevd ├ 2160 /sbin/udevd └ 2162 /sbin/udevd
Здесь есть масса информации. Указан файл настройки модуля (udev.service); а поместив процесс в группу (cgroup) systemd:/system/udev.service, systemd отслеживает не только родительский процесс демона (410), но и два дочерних (2160 и 2162). Мы также видим два других процесса, запущенных вместе с udev (459 и 443), и даже статусы их завершения.
Сервисы и группы
- Метамодернизм в позднем творчестве В.Г. Сорокина
- ЛитРПГ - последняя отрыжка постмодерна
- "Ричард III и семиотика"
- 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
- Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
- Литература
- Метамодерн
- Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
- Как избавиться от комаров? Лучшие типы ловушек.
- Что делать если роблокс вылетает на windows
- Что делать, если ребенок смотрит порно?
- Почему собака прыгает на людей при встрече?
- Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
- О чем может рассказать хвост вашей кошки?
- Верветки
- Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
- Срок исковой давности как правильно рассчитать
- Дмитрий Патрушев минсельхоз будет ли преемником Путина
- Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
- Как правильно выбрать машинное масло в Димитровграде?
- Как стать богатым и знаменитым в России?
- Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
- Как стать мудрецом?
- Как правильно установить FreeBSD
- Как стать таким как Путин?
- Где лучше жить - в Димитровграде или в Ульяновске?
- Почему город Димитровград так называется?
- Что такое метамодерн?
- ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
- Тарифы на электроэнергию для майнеров предложено повысить
В традиционной системе Linux понять, какие процессы принадлежат данному сервису, может быть непросто. На имя исполняемого файла можно положиться не всегда, а связь с родительским процессом демоны часто разрывают путем «двойного ветвления». Однако дочерние процессы наследуют группу от родителя, а процессы, выполняющиеся не от имени root, не могут покинуть свою группу cgroup. Помещая сервис в группу, названную по имени сервиса, systemd получает гарантированный способ определения всех процессов, относящихся к этому сервису. Например, сигнал всем процессам, относящимся к сервису crond (группа crond.service) можно отправить командой
# systemctl kill crond.service
В пакете systemd есть утилита systemd-cgls, которая выводит список групп. Без параметров она выводит список групп, управляемых systemd. Приведенный ниже список сокращен.
$ systemd-cgls └ system ├ 1 sbin.init ├ sshd.service │└ 2276 /usr/sbin/sshd ├ auditd.service │├ 874 auditd │├ 876 /sbin/audispd │└ 877 /usr/sbin/sedispatch
В репозитории Rawhide также есть пакет systemd-gtk с графической утилитой systemadm для просмотра и управления модулями systemd. В ней можно получить информацию о состоянии модулей и их зависимостях и даже остановить и запустить модули.
Настройка
Настройки модулей содержатся в текстовых файлах, расположенных в каталогах /lib/systemd/system и /etc/systemd/system. Первый – сфера деятельности менеджеров пакетов, второй предназначен для локальных администраторов. Файлы с конфигурацией сервисов имеют расширение SERVICE, точек монтирования – MOUNT, и т. д. В сущности, файлы SERVICE – это замена загрузочным скриптам System V, но systemd создает модули и из обычных скриптов Sys V. Аналогично, файлы MOUNT служат заменой традиционному /etc/fstab, задавая используемые точки монтирования и опции монтирования. Systemd предоставляет обратную совместимость, создавая точки монтирования и из записей старого доброго fstab.
Рассмотрим пример файла настройки – в данном случае, это /lib/systemd/system/avahi-daemon.service. Номера строк даны для удобства ссылок.
1. [Unit] 2. Description=Avahi mDNS/DNS-SD Stack 3. Requires=avahi-daemon.socket 4. After=syslog.target 5. 6. [Service] 7. Type=dbus 8. BusName=org.freedesktop.Avahi 9. ExecStart=/usr/sbin/avahi-daemon -s 10. ExecReload=/usr/sbin/avahi-daemon –r 11. NotifyAccess=main 12. 13. [Install] 14. WantedBy=multi-user.target 15. Also= avahi-daemon.socket 16. Alias=dbus-org.freedesktop.Avahi.service
Разберем некоторые строки более подробно. Строка 3 задает зависимости: при активации модуля также будут активированы перечисленные в ней модули. Так как все большее количество сервисов «гуляют сами по себе», явно задается все меньшее количество зависимостей. Строка 4 определяет порядок запуска; она велит systemd запускать сервис Avahi только после syslog.target. Обратите внимание, что зависимость и порядок запуска определяются независимо друг от друга. Можно сказать, что A требует B, но если не указать явно, что A следует запускать после B, они запустятся одновременно. Наконец, строка 9 определяет команду, выполняемую при запуске сервиса.
На смену традиционному /etc/inittab – первому источнику информации о событиях во время загрузки – приходит модуль default.target. В Rawhide ему соответствует файл /etc/systemd/system/default.target, символическая ссылка на /lib/systemd/system/graphical.target. Это в какой-то степени соответствует определению уровня выполнения по умолчанию. Отсюда цепочка зависимостей, заданная в файлах настройки модулей, с помощью ключевых слов Requires и Works вызывает необходимые цели, запускает сервисы и монтирует файловые системы.
Отмечу, что миграция на systemd – дело непростое. Придется приложить немало усилий, и Леннарт в своем блоге и на man-страницах постарался объяснить, зачем он разработал эту систему. Но она идет по пятам Upstart, и я уверен, что не всем будет охота связываться с изучением нового механизма управления сервисами.
Преимущества для всех
Когда я занимался разработкой научного ПО, то хорошо знал: чтобы ускорить выполнение программы, нужно проанализировать внутренние вложенные циклы в коде, которые выполняются миллионы раз. С этой точки зрения, процесс загрузки – последнее, что стоит оптимизировать. Однако для нетбуков, планшетов и других встроенных устройств потенциальное сокращение с systemd времени загрузки на несколько секунд – большой плюс. Для серверов, время холодной загрузки которых часто меньше, чем таймауты в BIOS, это не такая большая проблема. Тем не менее, улучшение управляемости и масштабируемость, вносимые systemd, должны вызвать улыбку и на суровых лицах сисадминов. Леннарт также намекнул, что на подходе – поддержка управления кластерами.
Где узнать больше
Бурное обсуждение обоснования архитектуры systemd ведется в блоге Леннарта. (Начните с http://0pointer.de/blog/projects/systemd-for-admins-1.html). Man-страницы доступны на http://0pointer.de/public/systemd-man, они очень подробны и хорошо написаны. В данный момент поработать с systemd вживую непросто. Попробуйте установить Rawhide (инструкции по установке см. на http://fedoraproject.org/wiki/Releases/Rawhide), но помните, что релиз тестирован не до конца, и не найдейтесь, что дорога будет торной.