http://wiki.linuxformat.ru/wiki/index.php?action=history&feed=atom&title=LXF143%3ADrBrown3 2026-05-13T13:07:09Z История изменений этой страницы в вики MediaWiki 1.19.20+dfsg-0+deb7u3 http://wiki.linuxformat.ru/wiki/index.php?title=LXF143:DrBrown3&diff=14309&oldid=prev 2012-09-03T08:03:40Z

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

Crazy Rebel