LXF137:Что за штука
Материал из Linuxformat
Версия от 12:11, 8 января 2012; Crazy Rebel (обсуждение | вклад)
|
|
|
Что за штука… SystemD?
- Скоро ваш любимый дистрибутив Linux будет загружаться гораздо быстрее, благодаря трем разработчикам-добровольцам. Пусть Боб Мосс все объяснит...
- Разве моя система грузится недостаточно быстро?
- Ну, во-первых, это весьма субъективный вопрос! А во-вторых, для запуска фоновых служб и загрузки системы большинство современных дистрибутивов применяет устаревший sysvinit или Upstart от Canonical. Последний активно пошел в ход в большинстве крупных Linux’ов в последние год-два, и это привело к значительному ускорению загрузки.
- А что это за sysvinit, о котором вы упомянули?
- Это процесс, родительский для любого процесса, работающего в системе Linux. Если точнее, ядро запускает sysvinit (обычно это /sbin/init) для того, чтобы активировать «подпрограммы», из которых затем компонуются фоновые службы. Sysvinit вызывает все компоненты системы и подчинённые службы в определённом порядке, поэтому является важнейшей частью ОС.
- Если sysvinit — важнейшая часть, почему вы обзываете её устаревшей?
- Sysvinit был создан задолго до появления современных ОС, а в нынешних условиях стал излишне громоздким и неэффективным. Процессы загружаются один после другого и строго поодиночке – то есть потенциал аппаратного обеспечения используется слабо (если не говорить об архаичных одноядерных процессорах). Или возьмём широкое использование скриптов оболочки. В общем-то криминала в этом нет, но ведь для каждого скрипта sysvinit загружает все модули оболочки, запускает службу, выполняет команды, останавливает службу и выгружает модули. Нетрудно догадаться, что все эти действия изрядно тормозят процесс, и те дистрибутивы, которые до сих пор используют отсталую технологию, по скорости загрузки (по крайней мере, в расчете на один сервис) не идут ни в какое сравнение с более продвинутыми собратьями.
- Полагаю, Upstart и есть та технология, которая идет на смену?
- Вы схватываете на лету! Upstart создал Скотт Джеймс Ремнант [Scott James Remnant] в свободное время, стараясь ускорить загрузку Linux. После того, как работу Скотта включили в основной проект Ubuntu (а в Canonical осознали, что автор – не кто иной, как их сотрудник), авторское право перешло к компании. В сообществе ходили слухи о том, что автору весьма настоятельно рекомендовали так поступить – однако, независимо от слухов и политических интриг, технология оказалась весьма полезной и, возможно, прямо сейчас работает в вашей системе.
- Хотите сказать, в моей системе орудует Upstart, а я и знать не знаю об этом?
- Если вы пользуетесь одним из основных современных дистрибутивов – скорее всего, всё так и есть, и Upstart извлекает намного больше пользы из вашей машины, чем sysvinit. Методику Upstart можно условно назвать «правилами действий». Эти правила предписывают, например, следующее: служба, запускаемая по некому событию, не может работать, если не запущены службы X и Y, и не должна работать одновременно со службой Z (так как они конфликтуют); а после запуска данной службы должны быть запущены модули A, B и C. Каждое правило действия связывается с определённым событием, которое может быть чем угодно, от запуска программного пакета до подключения USB-накопителя. Upstart работает в динамике и обеспечивает запуск всех служб, необходимых для обработки любого события, согласно предписанным правилам действия.
- Тогда зачем придумывать ещё какой-то SystemD?
- Не всё идеально и в технологии Upstart. Во-первых, программист должен определить правила действия для всех мыслимых событий, ведь сценариев ситуации может быть великое множество. Нужно указать каждый модуль и каждую службу, которые следует загрузить до, после и во время выполнения каждого правила, а также описать возможные конфликты. Кроме того, поскольку при работающем Upstart нельзя узнать, что именно было тем самым событием, при серьезных сбоях очень трудно добыть полезные диагностические сведения. Добавьте сюда попрежнему интенсивное использование оболочки для совместимости с sysvinit', особое отношение к процессам D-Bus – и вы поймёте, что причин заменить Upstart чем-нибудь более эффективным очень даже хватает.
- Кто разрабатывает SystemD?
- Над SystemD работают: Леннарт Поттеринг [Lennart Poettering] (сотрудник Red Hat, отвечает за разработку PulseAudio); Кай Сиверс [Kay Sievers] (из Novell) и Дхавал Гиани [Dhaval Giani] (ранее работал в IBM). Как и с Upstart, программисты пишут SystemD в свободное от основной работы время: никакая компания специально этим не занимается. Идею уже поприветствовали корифеи свободного ПО: многие из них негативно относятся к вопросам авторского права на Upstart. Название SystemD образовано по общим правилам именования работающих демонов (например, clamd) и недвусмысленно свидетельствует о тотальном влиянии на систему.
- Каковы же главные достоинства SystemD?
- Во-первых, разработчики намерены свести к минимуму использование оболочки, а сценарии sysvinit исполнять параллельно, для повышения быстродействия. Во-вторых, в SystemD не используются правила и события для руководства выполнением процессов, служб и модулей. Вместо этого различные объекты – например, службы, сокеты, устройства, точки монтирования, цели и снимки системы – определяются как «модули» (units), которые можно запускать, останавливать, перезагружать и перезапускать так же, как любой процесс. Программистам станет удобнее, поскольку SystemD сам создаёт и прослушивает сокеты: теперь работы по определению длинного перечня условий и действий для каждого события станет меньше. Управление привилегиями также осуществляет SystemD: для этого применяются те же «контрольные группы», что и в ядре Linux. Наконец, программистам больше не нужно заботиться о ‘sid’, вызовах PID-файлов и разветвлении процессов. Короче говоря, SystemD берёт на себя изрядную долю забот программиста и централизует управление «модулями», ради повышения эффективности загрузки.
- Эй, а зачем здесь контрольные группы?
- В ядре Linux эти группы определяют доступ процессов к ресурсам (файлам, ОЗУ и пр.) системы. SystemD применяет их для предоставления создаваемым «модулям» доступа в пределах полномочий определённой группы, выйти за которые они могут только по особому дозволению программиста, если он повысит полномочия до root. Всё это убирает много лишней работы, сберегая время программистов для кодирования.
- А почему разветвление процессов — это плохо?
- Если родительский процесс создаст другой процесс, тот станет «наследником» процесса-создателя. Это способно привести к возникновению массы клонов в системе, и если родительскому процессу присвоены повышенные полномочия, все его потомки приобретут те же привилегии, что непрактично и небезопасно.
- Почему параллельная работа скриптов sysvinit повышает быстродействие?
- Как я уже упоминал, sysvinit не слишком эффективен, а в его скриптах может со держаться информация, ненужная и даже вредная для работы SystemD. Скрипты обрабатываются почти так же, как процессы D-Bus, и это имеет смысл, если припомнить, что D-Bus запускает процессы параллельно, а не последовательно (в отличие от sysvinit). Вот и SystemD обрабатывает процессы параллельно, в русле D-Bus, тогда как sysvinit – по одному, в заданном порядке. Естественно, подход SystemD гораздо эффективнее использует мощь современных машин.
- Когда же SystemD придёт и на мою систему?
- Во время написания статьи новая технология носила статус экспериментальной, будучи в интенсивной разработке, но в новых версиях некоторых дистрибутивов, например Fedora 14, уже планируется заменить Upstart на SystemD для ускорения загрузки и общего повышения быстродействия.
- Неужели так скоро?! А где можно узнать об этом подробнее?
- Лучше всего начать отсюда: http://0pointer.de/blog/projects/systemd.html. Это исходный пост в блоге ведущего разработчика: здесь подробно разъясняются основы SystemD; а комментарии тоже достойны прочтения. Можно попытаться применить новинку и на существующей системе: руководство для OpenSUSE 11.3 выложено на http://bit.ly/aDGtZL.