From 0e79197eb123850ff7f701393cef45ebec3e2940 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Fri, 3 May 2013 00:18:00 +0400 Subject: [PATCH] Version v15.3 (2013-05-03 00:18) [AUTO] --- s4a.tex | 440 +++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 418 insertions(+), 22 deletions(-) diff --git a/s4a.tex b/s4a.tex index 59653ca..fb8ccd3 100644 --- a/s4a.tex +++ b/s4a.tex @@ -22,6 +22,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}} {\smallskip\par} \newcommand{\sfnote}[1]{\texorpdfstring{\protect\footnote% {Прим. перев.: #1}}{}} +\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\par Ответ:} % Настройка макета страницы \setlength{\hoffset}{-1.5cm} \addtolength{\textwidth}{2cm} @@ -76,6 +77,8 @@ Unported}} \end{flushright} \section{Контроль процесса загрузки} +\label{sec:verify} + Как правило, во время загрузки Linux по экрану быстро пробегает огромное количество различных сообщений. Так как мы интенсивно работаем над параллелизацией и ускорением процесса загрузки, с каждой новой версией @@ -234,6 +237,8 @@ systemd сообщает нам, что ntpd был запущен (с иден возникшие во время исполнения службы. \section{О службах и процессах} +\label{sec:cgls} + В большинстве современных Linux-систем количество одновременно работающих процессов обычно весьма значительно. Понять, откуда взялся и что делает тот или иной процесс, становится все сложнее и сложнее. Многие службы используют @@ -3341,6 +3346,7 @@ StartLimitAction=reboot-force заслуга реализации сторожевого контроля в systemd. \section{Запуск getty на последовательных (и не~только) консолях} +\label{sec:getty} \emph{Если вам лень читать всю статью целиком: для запуска getty на последовательной консоли\footnote{Прим. перев.: Здесь и в дальнейшем автор @@ -3488,15 +3494,15 @@ getty\footnote{Отметим, что +systemctl enable+ \emph{для экзем более ранних версиях придется напрямую манипулировать символьными ссылками: \texttt{ln -s /usr/lib/systemd/system/serial-getty@.service /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service ; systemctl -daemon-reload}.}\footnote{Прим. перев.: На самом деле, работать с символьными -ссылками придется даже в современных версиях systemd (на момент написания этих -строк, последней является версия 202), так как разработчики забыли включить в -файл +serial-getty@.service+ секцию +[Install]+, в результате чего попытка -выполнения +systemctl enable+ для экземпляра соответствующей службы ведет к -закономерной ошибке. Впрочем, исправить это несложно: достаточно скопировать -данный файл в +/etc/systemd/system/+, после чего дописать в него секцию -+[Install]+ с параметром +WantedBy=getty.target+, а затем выполнить -+systemctl daemon-reload+.}: +daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На самом деле, +работать с символьными ссылками придется даже в современных версиях systemd (на +момент написания этих строк, последней является версия 202), так как +разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+, +в результате чего попытка выполнения +systemctl enable+ для экземпляра +соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это +несложно: достаточно скопировать данный файл в +/etc/systemd/system/+, после +чего дописать в него секцию +[Install]+ с параметром +WantedBy=getty.target+, а +затем выполнить +systemctl daemon-reload+.}: \begin{Verbatim} # systemctl enable serial-getty@ttyS2.service # systemctl start serial-getty@ttyS2.service @@ -4612,6 +4618,271 @@ systemd, начиная с версии 197. Тем не~менее, наша р \appendix +\section{FAQ (часто задаваемые вопросы)\sfnote{Перевод статьи +<<\href{http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions}% +{Frequently Asked Questions}>> с официального сайта проекта, по состоянию на +2013-01-15 16:59:29 (ревизия \No29).}} + +Также смотрите статью +\href{http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks}{Tips \& +Tricks}\footnote{Прим. перев.: На самом деле, смотреть там особо не~на что. +Б\'{о}льшая часть приведенного там материала вполне соответствует формату FAQ, и +поэтому была перенесена в текущую главу. Исключением являются только +<> и <>, но они подробно рассмотрены в +главе~\ref{sec:cgls}.}. + +\qna{Как изменить текущий уровень выполнения (runlevel)?} +В systemd уровни выполнения оформлены в виде целевых состояний (target units). +Команда перехода в заданное состояние выглядит так: +\begin{Verbatim} +# systemctl isolate runlevel5.target +\end{Verbatim} + +Отметим, что концепция уровней исполнения уже порядком устарела, и вместо +номеров уровней удобнее оперировать более выразительными именами целевых +состояний: +\begin{Verbatim} +# systemctl isolate graphical.target +\end{Verbatim} + +Подобные команды изменят только текущий уровень выполнения. Их действие никак +не~повлияет на последующие загрузки системы. + +\qna{Как изменить уровень выполнения, в который система грузится по умолчанию?} +Соответствующее целевое состояние задается символьной ссылкой ++/etc/systemd/system/default.target+. Для его смены достаточно перезаписать эту +ссылку. Например, так: +\begin{Verbatim} +# ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target +\end{Verbatim} +или так +\begin{Verbatim} +# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target +\end{Verbatim} + +\qna{Как узнать текущий уровень выполнения?} +В один и тот же момент времени может быть активно несколько целевых состояний, +поэтому понятие текущего уровня выполнения (единственного и однозначно +определенно) применимо уже далеко не~всегда. Узнать, какие состояния сейчас +активны, вы можете при помощи команды +\begin{Verbatim} +$ systemctl list-units --type=target +\end{Verbatim} + +Если вам нужна именно одна цифра, вы можете воспользоваться классической +командой +runlevel+, однако, по изложенным выше причинам, она далеко не~всегда +способна адекватно оценить текущую ситуацию. + +\qna{Я изменил service-файл, но пакетный менеджер перезаписывает мои изменения +при каждом обновлении. Что делать?} +Наиболее разумным решением будет скопировать исходный файл из ++/usr/lib/systemd/system+ в +/etc/systemd/system+ и внести изменения в +полученную копию. Файлы из +/etc+ защищены от посягательств пакетного менеджера, +и при этом имеют приоритет над файлами из +/usr+. Если же вы захотите вернуться +к настройкам по умолчанию, достаточно будет просто удалить или переименовать +созданный вами файл\footnote{Прим. перев.: Начиная с версии systemd 198, +необязательно копировать файл целиком, если вы хотите добавить/изменить +отдельные настройки. Можно просто создать в +/etc/systemd/system/+ подкаталог ++имя_службы.service.d+, а в нем~--- файл с именем, заканчивающимся на +.conf+, +например, +mysettings.conf+, после чего вписать в этот файл необходимые +настройки. Они будут применены <<поверх>> настроек из штатного файла +(расположенного в +/usr+).}. + +\qna{Служба foo.service по умолчанию запускается только при поступлении +входящего соединения (или подключении определенного оборудования, или при +появлении заданного файла). Как сделать так, чтобы она запускалась сразу при +загрузке?} +Достаточно поместить символьную ссылку на соответствующий service-файл в каталог ++multi-user.target.wants/+. +\begin{Verbatim} +# ln -sf /usr/lib/systemd/system/foobar.service \ +> /etc/systemd/system/multi-user.target.wants/foobar.service +# systemctl daemon-reload +\end{Verbatim} + +В это каталоге содержатся ссылки на все юниты, которые нужно запустить в +состоянии multi-user (эквивалент уровня выполнения 3, т.е. загрузка с запуском +всех служб, но не~графического интерфейса). Так как цель +graphical.target+ +тянет по зависимости и +multi-user.target+, то ваша служба будет запущена также +и при <<графических>> загрузках. + +\qna{Я хочу запустить еще один экземпляр getty, как это сделать?} +Для запуска getty на последовательном порту, достаточно запустить +соответствующий экземпляр службы +serial-getty@.service+: +\begin{Verbatim} +# systemctl start serial-getty@ttyS2.service +\end{Verbatim} + +Чтобы обеспечить автоматически запуск getty на этом порту при каждой загрузке, +нужно поместить соответствующую символьную ссылку в каталог ++getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда ++systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней +мере, в версиях до 202 включительно). Подробнее +см.~примечание~\ref{ftn:enableserial}.}: +\begin{Verbatim} +# ln -s /usr/lib/systemd/system/serial-getty@.service \ +> /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service +# systemctl daemon-reload +\end{Verbatim} + +Обратите внимание, что на виртуальных терминала getty запускаются автоматически, +как только пользователь переключается на данный терминал. Максимальное +количество таких терминалов задается параметром +NAutoVTs=+ в файле +\href{http://www.freedesktop.org/software/systemd/man/logind.html}% +{logind.conf(7)}. Также см. главу~\ref{sec:getty}. + +\qna{Как узнать, какой службе принадлежат вот эти процессы?} +Для этого можно воспользоваться командой +ps+ +\begin{Verbatim}[fontsize=\small] +$ alias psc='ps xawf -eo pid,user,cgroup,args' +$ psc + PID USER CGROUP COMMAND +... + 1 root name=systemd:/systemd-1 /bin/systemd systemd.log_target=kmsg systemd.log_level=debug selinux=0 + 415 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d + 928 root name=systemd:/systemd-1/atd.service /usr/sbin/atd -f + 930 root name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n + 932 root name=systemd:/systemd-1/crond.service /usr/sbin/crond -n + 935 root name=systemd:/systemd-1/auditd.service /sbin/auditd -n + 943 root name=systemd:/systemd-1/auditd.service \_ /sbin/audispd + 964 root name=systemd:/systemd-1/auditd.service \_ /usr/sbin/sedispatch + 937 root name=systemd:/systemd-1/acpid.service /usr/sbin/acpid -f + 941 rpc name=systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f + 944 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c 4 + 947 root name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger + 950 root name=systemd:/systemd-1/cups.service /usr/sbin/cupsd -f + 955 dbus name=systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation + 969 root name=systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6 + 970 root name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5 + 971 root name=systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1 + 973 root name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4 + 974 root name=systemd:/user/lennart/2 login -- lennart + 1824 lennart name=systemd:/user/lennart/2 \_ -bash + 975 root name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3 + 988 root name=systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd + 994 rtkit name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon +... +\end{Verbatim} +или просто посмотреть \verb+/proc/$PID/cgroup+. Также см. главу~\ref{sec:cgls}. + +\qna{Почему вы не~используете infotify для отслеживания изменений в настройках?} +К сожалению, реализовать это весьма проблематично. За подробностями вы можете +обратиться к обсуждению этой проблемы в +\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}\footnote{Прим. +перев.: Вкратце, суть проблемы состоит в том, что перемещение/переименование +файла не~является атомарной операцией, а состоит из удаления одного файла и +создания другого. Эти операции могут следовать в произвольном порядке с +некоторым интервалом, что может привести к временному исчезновению службы, либо +к появлению двух конфликтующих служб.}. + +\qna{У моей службы есть как штатный service-файл, так и init-скрипт (с тем же +именем). Какой из этих файлов главнее~--- +\texttt{/usr/lib/systemd/system/foobar.service} или +\texttt{/etc/init.d/foobar}?} +При наличии обоих этих файлов, приоритет всегда отдается штатному service-файлу, +независимо от того, включен ли запуск соответствующего скрипта (например, через ++chkconfig+) или нет. Обратите внимание, что отключение юнит-файла (например, +через +systemctl disable+ приведет к полному отключению службы, даже если +init-скрипт при этом будет включен. + +\qna{Как заставить \texttt{journalctl} выводить полные (не~сокращенные строки)?} +Используйте +\begin{Verbatim} +# journalctl --full +\end{Verbatim} + +\qna{Моя служба пытается получить приоритет реального времени, но получает +ошибку EPERM, хотя обладает всеми необходимыми привилегиями. А без вашего +systemd все работало!} +По умолчанию, systemd помещает каждую системную службу в собственную контрольную +группу контроллера +cpu+. К сожалению, из-за существующего в реализации данного +контроллера ограничения, это приводит к невозможности получения приоритета +реального времени для служб. Подробное обсуждение этой проблемы и методы ее +решения смотрите в приложении~\ref{sec:realtime}. + +\qna{Моя служба настроена на запуск после \texttt{network.target}, однако она +все равно запускается раньше, чем появляется сеть. Почему?} +Это длинная история. См. приложение~\ref{sec:networktarget}. + +\qna{systemd монтирует в \texttt{/tmp} \texttt{tmpfs}. Как это отключить?} +Это тоже долгая история. См. приложения~\ref{sec:apifs}. + +\qna{Как просмотреть список работающих служб?} +Запустите команду +systemctl+ без параметров: +\begin{Verbatim}[fontsize=\small] +$ systemctl +UNIT LOAD ACTIVE SUB JOB DESCRIPTION +accounts-daemon.service loaded active running Accounts Service +atd.service loaded active running Job spooling tools +avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack +bluetooth.service loaded active running Bluetooth Manager +colord-sane.service loaded active running Daemon for monitoring attached scanners and registering them with colord +colord.service loaded active running Manage, Install and Generate Color Profiles +crond.service loaded active running Command Scheduler +cups.service loaded active running CUPS Printing Service +dbus.service loaded active running D-Bus System Message Bus +... +\end{Verbatim} + +\qna{Как узнать текущее состояние службы?} +Воспользуйтесь командой +systemctl status+: +\begin{Verbatim}[fontsize=\small] +$ systemctl status udisks2.service +udisks2.service - Storage Daemon + Loaded: loaded (/usr/lib/systemd/system/udisks2.service; static) + Active: active (running) since Wed, 27 Jun 2012 20:49:25 +0200; 1 day and 1h ago + Main PID: 615 (udisksd) + CGroup: name=systemd:/system/udisks2.service + └ 615 /usr/lib/udisks2/udisksd --no-debug + +Jun 27 20:49:25 epsilon udisksd[615]: udisks daemon version 1.94.0 starting +Jun 27 20:49:25 epsilon udisksd[615]: Acquired the name org.freedesktop.UDisks2 on the system message bus +\end{Verbatim} + +\qna{Как отследить зависимости между юнитами?} +Допустим, вы хотите узнать, какие юниты будут запущены при активации ++multi-user.target+: +\begin{Verbatim} +$ systemctl show -p "Wants" multi-user.target +Wants=rc-local.service avahi-daemon.service rpcbind.service +NetworkManager.service acpid.service dbus.service atd.service crond.service +auditd.service ntpd.service udisks.service bluetooth.service cups.service +wpa_supplicant.service getty.target modem-manager.service portreserve.service +abrtd.service yum-updatesd.service upowerd.service test-first.service +pcscd.service rsyslog.service haldaemon.service remote-fs.target +plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service +lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service +iscsid.service livesys.service livesys-late.service irqbalance.service +iscsi.service netfs.service +\end{Verbatim} + +Вместо +Wants+ вы можете использовать другие типы зависимостей: +WantedBy+, ++Requires+, +RequiredBy+, +Conflicts+, +ConflictedBy+, +Before+, ++After+\footnote{Прим. перев.: Разница между \texttt{*s} и \texttt{*edBy}~--- +в направлении зависимости. Например, если \texttt{multi-user.target} запрашивает +запуск (\texttt{Wants}) юнита \texttt{rc-local.service}, то она будет +указана в свойстве \texttt{WantedBy} этого юнита. Интересно, что свойство +\texttt{ConflictedBy} существует, однако задать его вручную нельзя~--- оно +формируется только на основании \texttt{Conflicts} других служб. Что касается +разница между +Wants+ и +Requires+, то первое является пожеланием, а второе +требованием. Если \emph{требуемый} юнит не~сможет запуститься, значит +не~запустится и сам зависящий от него юнит. \emph{Пожелания} не~накладывают +такого ограничения. А указания \emph{порядка} запуска (\texttt{Before}, +\texttt{After}) вообще не~формируют зависимостей и работают только тогда, когда +такие зависимости, прямо или косвенно, уже заданы.}. + +\qna{Как узнать, что будет запущено при загрузке системы в заданное целевое +состояние?} +Вы можете заставить systemd рассчитать <<начальную>> транзакцию, определяющую +алгоритм загрузки в заданное состояние +foobar.target+: +\begin{Verbatim} +$ systemd --test --system --unit=foobar.target +\end{Verbatim} + +Обратите внимание, что эта команда предназначена исключительно для отладки, и ее +работа на самом деле не~ограничивается расчетом транзакции, поэтому не~стоит +вызывать ее в скриптах. + \section{Диагностика неполадок\sfnote{Перевод статьи <<\href{http://freedesktop.org/wiki/Software/systemd/Debugging}{Debugging systemd Problems}>> с официального сайта проекта, по состоянию на 2013-01-08 @@ -4925,6 +5196,127 @@ systemctl dump > systemd-dump.txt \end{Verbatim} \end{itemize} +\section{Совместимость с SysV\sfnote{Перевод статьи +<<\href{http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities}% +{Compatibility with SysV}>> с официального сайта проекта, по +состоянию на 2013-01-11 19:04:14 (ревизия \No26).}} + +systemd обеспечивает высокий уровень совместимости с поведением классической +системы инициализации SysV init, реализованной во многих дистрибутивах. Это +касается как непосредственного взаимодействия с пользователем, так и поддержки +API для скриптов. Тем не~менее, существует ряд ограничений, обусловленных +техническими соображениями, а также особенностями дизайна systemd и/или +дистрибутивов. Ниже приведен список таких ограничений. Большая их часть +затрагивает дистрибутивно-специфичные расширения SysV init, и поэтому будет +ощутима только для пользователей отдельных дистрибутивов. +\begin{itemize} + \item Если разработчики вашего дистрибутива отказались от SysV + init-скрипта в пользу штатного юнит-файла, прямой вызов этого + скрипта (например, +/etc/init.d/foobar start+), очевидно, + работать не~будет. Лучше воспользоваться стандартной и + универсальной командой +/sbin/service foobar start+, которая + одинаково хорошо работает как с systemd, так и с SysV init. + Отметим, что прямое обращение к скрипту в любом случае не~вполне + корректно, так как запущенная служба унаследует часть контекста + выполнения (переменные окружения, umask, ограничения по + ресурсам, идентификаторы аудита, и т.д.) от пользовательской + оболочки, из которой был запущен скрипт. Вызов скрипта через + +/sbin/service+ исправляет этот недостаток, пусть и частично. + Кроме того, стоит заметить, что стандарт LSB предписывает + обращаться к службам только через +/sbin/service+. + (Вышеуказанное ограничение \emph{не}~распространяется на + дистрибутивы, которые одновременно поддерживают и init-скрипты, + и юнит-файлы. В таких дистрибутивах даже прямое обращение к + скрипту при необходимости будет преобразовано в соответствующий + запрос к systemd.) + \item Информация о зависимостях служб, прописанная в LSB-заголовке + скрипта, играет существенную роль. Большинство реализаций SysV + в различных дистрибутивах практически не~используют эту + информацию, либо используют ее очень ограниченно. Вследствие + этого, информацию о зависимостях часто указывали некорректно + или не~полностью. В отличие от подобных реализаций, systemd + интерпретирует эти заголовки корректно, и использует + содержащуюся в них информацию при выполнении различных операций + со службами (а не~только в момент их установки, как это делают + некоторые другие реализации SysV.) + \item Все операции со скриптами ограничены по времени при помощи + тайм-аутов. В отличие от классических SysV-систем, где зависший + init-скрипт полностью останавливает загрузку, systemd + ограничивает максимальную длительность работы скрипта пятью + минутами. + \item Службы запускаются в совершенно чистом контексте исполнения. + Они уже не~наследуют контекст у оболочки, из которой был вызван + их скрипт. В частности, это касается специфических переменных, + таких как \verb+$HOME+. Как следствие, скрипты, их использующие, + не~смогут работать корректно. + \item Службы и их скрипты не~могут читать с STDIN~--- для них этот поток + подключен к +/dev/null+. Следовательно, интерактивные + init-скрипты не~поддерживаются (в частности, игнорируется + используемый в LSB-заголовках скриптов Debian флаг + +X-Interactive+). К счастью, большинство дистрибутивов все равно + не~поддерживали интерактивные init-скрипты. Если вашему скрипту + нужно запросить пароль для зашифрованного диска или + SSL-ключа, вы можете воспользоваться для этого специальным + механизмом, предоставляемым systemd (см. + \href{http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents}% + {описание} и + \href{http://www.freedesktop.org/software/systemd/man/systemd-ask-password.html}% + {страницу руководства}). + \item Дополнительные команды для init-скриптов (кроме стандартных, + таких, как +start+, +stop+, +status+ и т.д.) + не~поддерживаются\footnote{Прим. перев.: В частности, это + касается специфичных для init-скрипта +/etc/init.d/iptables+ + команд +save+ и +panic+.}. + \item Также не~поддерживается возможность указывать после стандартных + команд скрипту дополнительные параметры. Такое расширение SysV + не~прописано ни~в каких стандартах, и реализация его поддержки + была бы весьма проблематичной. + \item systemd останавливает только те службы, которые выполняются. + Традиционный SysV init при завершении + работы системы запускает все скрипты, предписанные +K*+-ссылками + для текущего уровня исполнения. systemd в аналогичной ситуации + действует более последовательно, и не~пытается остановить те + службы, которые не~были запущены. + \item Поддержка уровней исполнения (runlevels) в systemd имеет некоторые + ограничения. Хотя все уровни исполнения SysV имеют + соответствующие им целевые состояния (target units), далеко + не~все целевые состояния имеют соответствующие им уровни + исполнения. Это обусловлено тем, что механизм целевых состояний + отличается гораздо б\'{о}льшей гибкостью и эффективностью, + чем система уровней исполнения. Как следствие, в некоторых + случаях попытка узнать текущий уровень исполнения (например, + при помощи +/sbin/runlevel+) может вернуть <<+N+>> (т.е. + <<уровень выполнения неизвестен>>), что может привести к + нарушению работы скриптов, использующих явную проверку текущего + уровня исполнения. Избегайте подобных проверок. + \item +/sbin/chkconfig+ и аналогичные программы могут выводить + некорректную информацию о состоянии службы (включена/отключена). + Они оперируют только init-скриптами, игнорируя штатные + юнит-файлы. Кроме того, они опираются на механизм уровней + выполнения, который поддерживается не~полностью (см. выше). + \item По умолчанию, уровни исполнения 2, 3 и 4 являются эквивалентами + целевого состояния +multi-user.target+. Если включить службу на + одном из них, то она будет включена и на остальных. Впрочем, это + лишь настройка по умолчанию, и ничто не~мешает вам определить их + независимо. Тем не~менее, мы рекомендуем отказаться от уровней + исполнения в пользу более гибкого механизма целевых состояний + systemd. + \item Дистрибутивно-специфичные квази-уровни исполнения, используемые + для организации запуска скриптов на ранних стадиях загрузки, больше + не~поддерживаются\footnote{Прим. перев.: Начиная с версии 196, + см. коммит + \href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=3cdebc217c42c8529086f2965319b6a48eaaeabe}% + {3cdeb} от 16 ноября 2012 г.}. Примерами таких уровней являются + +S+ в Debian и +b+ в openSUSE. Разумеется, это никак + не~затрагивает поддержку обычных уровней исполнения, которую мы + намерены сохранять еще очень долго. + \item По умолчанию, SysV-службы не~могут получить приоритет реального + времени, даже если располагают полными привилегиями. За + подробностями и методами решения обратитесь к + приложению~\ref{sec:realtime}. +\end{itemize} + + \section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи <<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}% {Predictable Network Interface Names}>> с официального сайта проекта, по @@ -5001,16 +5393,17 @@ systemd/udev\footnote{Прим. перев.: См. коммит В частности, udev теперь штатно поддерживает следующие механизмы именования сетевых интерфейсов: \begin{enumerate} - \item Схема именования для устройств, встроенных в материнскую плату (на - основании информации от EFI/BIOS), например: +eno1+. - \item Схема именования для устройств, подключенных в слоты PCI Express - (также на основании информации от EFI/BIOS), например: +ens1+. - \item Схема именования, основанная на физическом расположении точки - подключения оборудования, например, +enp2s0+. - \item Схема именования на основании MAC-адреса, например, + \item Имена устройств, встроенных в материнскую плату, формируются на + основании информации от прошивки\footnote{Прим. перев.: + BIOS, (U)EFI, SPARC Boot PROM, \ldots.}, например: +eno1+. + \item Имена устройств, подключенных в слоты PCI Express, формируются + также на основании информации от прошивки, например: +ens1+. + \item Имена устройств формируются исходя из физического расположении + точки подключения оборудования, например, +enp2s0+. + \item Имена устройств формируются на основе их MAC-адресов, например, +enx78e7d1ea46da+. - \item Классические, непредсказуемые имена, присвоенные ядром, например, - +eth0+. + \item Используются классические, непредсказуемые имена, присвоенные + ядром, например, +eth0+. \end{enumerate} По умолчанию, systemd 197 при именовании сетевых интерфейсов последовательно @@ -5164,6 +5557,7 @@ Multi-function PCI устройство с двумя портами: <<\href{http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems}{API File Systems}>> с официального сайта проекта, по состоянию на 2013-01-17 11:06:59 (ревизия \No14).}} +\label{sec:apifs} \emph{Итак, вы запустили программу mount(8), и увидели в ее выводе множество странных файловых систем, не~указанных в /etc/fstab. У вас могут возникнуть @@ -5272,6 +5666,7 @@ systemctl mask tmp.mount <<\href{http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget}{Running Services After the Network is up}>> с официального сайта проекта, по состоянию на 2013-01-17 23:22:58 (ревизия \No17).}} +\label{sec:networktarget} \emph{Итак, ваша служба настроена на запуск только после достижения цели network.target, однако, несмотря на это, она все равно запускается до появления @@ -5425,6 +5820,7 @@ service-файл, запускающий любую заданную вами п <<\href{http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime}% {My Service Can't Get Realtime!}>> с официального сайта проекта, по состоянию на 2013-01-15 16:54:09 (ревизия \No1).}} +\label{sec:realtime} \emph{Итак, у вас есть служба, которая требует приоритет реального времени (realtime). Однако, когда вы пытаетесь запустить ее на системе, работающей под @@ -5479,10 +5875,10 @@ systemd не~может присваивать такой бюджет \emph{к {документации к ядру}. \end{itemize} -Последние две опции недоступны для SysV-служб. Тем не~менее, вы можете -подготовить для них соответствующие service-файлы, которые, помимо упомянутых -выше параметров, содержат вызов соответствующего init-скрипта с аргументом -+start+ в +ExecStart=+, и с аргументом +stop+~--- в +ExecStop=+. +Последние две опции неприменимы к SysV-службам. Тем не~менее, вы можете +подготовить для таких служб соответствующие service-файлы, которые, помимо +упомянутых выше параметров, содержат вызов соответствующего init-скрипта с +аргументом +start+ в +ExecStart=+, и с аргументом +stop+~--- в +ExecStop=+. (Также имеет смысл задать для них параметры +RemainAfterExit=1+ и +Type=forking+.)