Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
0e79197eb1 |
440
s4a.tex
440
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, и
|
||||
поэтому была перенесена в текущую главу. Исключением являются только
|
||||
<<cgroup tree>> и <<ps with cgroups>>, но они подробно рассмотрены в
|
||||
главе~\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+.)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user