Материал из Linuxformat.

Содержание 1 Ре­фор­мы про­цес­са за­груз­ки 1.1 Раз­ду­вание про­цес­са­ми 1.2 Сер­ви­сы и груп­пы 1.3 На­строй­ка 1.4 Пре­иму­ще­ст­ва для всех 1.5 Где уз­нать боль­ше

Ре­фор­мы про­цес­са за­груз­ки

По­ка борют­ся ти­та­ны за­груз­ки, док­тор изу­ча­ет отважно­го но­вич­ка.

В ста­рые до­б­рые вре­ме­на про­цесс за­груз­ки 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), и да­же ста­ту­сы их за­вер­шения.

Сер­ви­сы и груп­пы

В тра­ди­ци­он­ной сис­те­ме 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), но пом­ни­те, что ре­лиз тес­ти­ро­ван не до кон­ца, и не найдей­тесь, что до­ро­га будет тор­ной.