Compare commits
3 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
97ba7a7ac6 | ||
|
|
8af5fceade | ||
|
|
0e79197eb1 |
633
s4a.tex
633
s4a.tex
@@ -22,6 +22,9 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
{\smallskip\par}
|
||||
\newcommand{\sfnote}[1]{\texorpdfstring{\protect\footnote%
|
||||
{Прим. перев.: #1}}{}}
|
||||
\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\par Ответ:}
|
||||
\newcommand\yousaywtf[1]{\emph{#1}}
|
||||
\newcommand\yousaywtfsk[1]{\yousaywtf{#1}\medskip\par}
|
||||
% Настройка макета страницы
|
||||
\setlength{\hoffset}{-1.5cm}
|
||||
\addtolength{\textwidth}{2cm}
|
||||
@@ -34,6 +37,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
% И листингов
|
||||
\definecolor{gray}{gray}{0.75}
|
||||
\fvset{frame=leftline,rulecolor=\color{gray},framerule=1mm}
|
||||
\definecolor{dgreen}{rgb}{0,0.6,0}
|
||||
% Запрет висячих строк
|
||||
\clubpenalty=10000
|
||||
\widowpenalty=10000
|
||||
@@ -51,7 +55,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
Unported}}
|
||||
\maketitle
|
||||
\tableofcontents
|
||||
\newpage
|
||||
%\newpage
|
||||
\sectiona{Предисловие автора}
|
||||
Многие из вас, наверное, уже знают, что
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это новая
|
||||
@@ -76,6 +80,8 @@ Unported}}
|
||||
\end{flushright}
|
||||
|
||||
\section{Контроль процесса загрузки}
|
||||
\label{sec:verify}
|
||||
|
||||
Как правило, во время загрузки Linux по экрану быстро пробегает огромное
|
||||
количество различных сообщений. Так как мы интенсивно работаем над
|
||||
параллелизацией и ускорением процесса загрузки, с каждой новой версией
|
||||
@@ -85,7 +91,7 @@ systemd эти сообщения будут пробегать все быст
|
||||
сообщения. Тем не~менее, информация, которую они несут, была и остается
|
||||
чрезвычайно важной~--- они показывают, успешно ли запустилась каждая служба, или
|
||||
попытка ее запуска закончилась ошибкой (зеленое
|
||||
\texttt{[~\textcolor{green}{OK}~]} или красное
|
||||
\texttt{[~\textcolor{dgreen}{OK}~]} или красное
|
||||
\texttt{[~\textcolor{red}{FAILED}~]} соответственно). Итак, с ростом скорости
|
||||
загрузки систем, возникает неприятная ситуация: информация о результатах
|
||||
запуска служб бывает очень важна, а просматривать ее все тяжелее. systemd
|
||||
@@ -234,6 +240,8 @@ systemd сообщает нам, что ntpd был запущен (с иден
|
||||
возникшие во время исполнения службы.
|
||||
|
||||
\section{О службах и процессах}
|
||||
\label{sec:cgls}
|
||||
|
||||
В большинстве современных Linux-систем количество одновременно работающих
|
||||
процессов обычно весьма значительно. Понять, откуда взялся и что делает тот
|
||||
или иной процесс, становится все сложнее и сложнее. Многие службы используют
|
||||
@@ -3341,6 +3349,7 @@ StartLimitAction=reboot-force
|
||||
заслуга реализации сторожевого контроля в systemd.
|
||||
|
||||
\section{Запуск getty на последовательных (и не~только) консолях}
|
||||
\label{sec:getty}
|
||||
|
||||
\emph{Если вам лень читать всю статью целиком: для запуска getty на
|
||||
последовательной консоли\footnote{Прим. перев.: Здесь и в дальнейшем автор
|
||||
@@ -3488,15 +3497,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 (на
|
||||
момент написания этих строк, последней является версия 204), так как
|
||||
разработчики забыли включить в файл +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 +4621,279 @@ 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{Служба \texttt{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+ работать не~будет (по крайней
|
||||
мере, в версиях до 204 включительно). Подробнее
|
||||
см.~примечание~\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{Почему вы не~используете inotify для отслеживания изменений в настройках?}
|
||||
К сожалению, реализовать это весьма проблематично. За подробностями вы можете
|
||||
обратиться к обсуждению в
|
||||
\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+ без параметров\footnote{Прим. перев.: +systemctl+
|
||||
без параметров выведет состояние всех активных юнитов (в т.ч. сокетов,
|
||||
устройств, точек монтирования, целевых состояний, таймеров, и т.д.). Чтобы
|
||||
ограничиться только службами, добавьте параметр +-t service+. Чтобы вывести все
|
||||
службы/юниты, включая неактивные, добавьте параметр +-a+.}:
|
||||
\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{\label{ftn:wants}Прим. перев.: Разница между +*s+ и +*edBy+~---
|
||||
в направлении зависимости. Например, если цель +multi-user.target+ запрашивает
|
||||
запуск (+Wants+) службы +rc-local.service+, то она будет
|
||||
указана в свойстве +WantedBy+ этой службы. Интересно, что свойство
|
||||
+ConflictedBy+ существует, однако задать его напрямую нельзя~--- оно
|
||||
формируется только на основании +Conflicts+ других служб. Что касается
|
||||
разницы между +Wants+ и +Requires+, то первое является пожеланием, а второе
|
||||
требованием. Если требуемый (required) юнит не~сможет запуститься, то
|
||||
не~запустится и сам зависящий от него юнит. Пожелания (wants) не~накладывают
|
||||
такого ограничения~--- будет сделана попытка запуска зависимого юнита, но
|
||||
результат ее никак не~отразится на зависящем юните. А указания \emph{порядка}
|
||||
запуска (+Before+, +After+) вообще не~формируют зависимостей и работают только
|
||||
тогда, когда такие зависимости, прямо или косвенно, уже заданы.}\footnote{Прим.
|
||||
перев. Отметим, что начиная с systemd 198, +systemctl+ поддерживает
|
||||
специализированную команду +list-dependencies+, позволяющую отследить прямые и
|
||||
косвенные (<<рекурсивные>>) зависимости заданного юнита.}.
|
||||
|
||||
\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
|
||||
@@ -4627,7 +4909,7 @@ systemd Problems}>> с официального сайта проекта, по
|
||||
\begin{Verbatim}[commandchars=\\\{\}]
|
||||
Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиза})}!
|
||||
Starting \emph{название}...
|
||||
[ \textcolor{green}{OK} ] Stared \emph{название}...
|
||||
[ \textcolor{dgreen}{OK} ] Stared \emph{название}...
|
||||
\end{Verbatim}
|
||||
(Пример можно посмотреть на
|
||||
\href{http://freedesktop.org/wiki/Software/systemd/Debugging?action=AttachFile&do=view&target=f17boot.png}{скриншоте}.)
|
||||
@@ -4635,13 +4917,12 @@ Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиз
|
||||
Если у вас есть доступ к оболочке, это значительно упрощает диагностику и
|
||||
решение проблем. В том случае, когда до приглашения входа в систему дело так и
|
||||
не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав
|
||||
CTRL--ALT--F<\emph{цифра}>. Дело в том, что при проблемах, связанных с запуском
|
||||
X-сервера, может возникать ситуация, когда на первой консоли (+tty1+)
|
||||
приглашение ко входу отсутствует, но все остальные консоли при этом работают
|
||||
нормально.
|
||||
CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может
|
||||
возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу
|
||||
отсутствует, но все остальные консоли при этом работают нормально.
|
||||
|
||||
Если ни~на одной из виртуальных консолей приглашение так и не~появилось~---
|
||||
попробуйте выждать еще \emph{порядка 5 минут}. Только после этого можно
|
||||
попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно
|
||||
будет считать процесс загрузки окончательно зависшим. Если подвисание
|
||||
обусловлено всего лишь сбоем при запуске какой-то службы, то после истечения
|
||||
тайм-аута проблемная служба будет убита, и загрузка продолжится. Другой
|
||||
@@ -4672,7 +4953,22 @@ X-сервера, может возникать ситуация, когда н
|
||||
на последовательную консоль: меню Вид (View)~$\Rightarrow$ Текстовые
|
||||
консоли (Text Consoles)), вы можете попросить systemd выводить на эту
|
||||
консоль подробную отладочную информацию о ходе загрузки, добавив к
|
||||
параметрам ядра следующие аргументы:
|
||||
параметрам ядра следующие аргументы\footnote{\label{ftn:netconsole}
|
||||
Прим. перев.: Стоит упомянуть еще об одном отладочном инструменте~---
|
||||
\hreftt{https://www.kernel.org/doc/Documentation/networking/netconsole.txt}%
|
||||
{netconsole}. Это механизм ядра, позволяющий отправлять содержимое
|
||||
буфера +kmsg+ (см.
|
||||
\hreftt{http://linux.die.net/man/8/dmesg}{dmesg(8)}) по сети на заданный
|
||||
компьютер. Обратите внимание, что его настройка через командную строку
|
||||
ядра (параметр +netconsole=...+) работает только если он вкомпилирован в
|
||||
ядро монолитно. Если же он собран модулем, его необходимо настраивать
|
||||
через +/etc/modprobe.d/*.conf+ или +configfs+ (впрочем, некоторые версии
|
||||
+modprobe+ поддерживают чтение параметров модулей из командной строки
|
||||
ядра, так что можно попробовать добавить туда
|
||||
+netconsole.netconsole=...+), а также задавать его принудительную
|
||||
подгрузку через параметр ядра +modules-load=netconsole+. Кроме того, при
|
||||
этом надо обеспечить перенаправление логов systemd в буфер ядра~---
|
||||
соответствующие параметры см. в разделе~\ref{sssec:kmsg}.}:
|
||||
\begin{Verbatim}
|
||||
systemd.log_level=debug systemd.log_target=console console=ttyS0,38400
|
||||
\end{Verbatim}
|
||||
@@ -4728,8 +5024,8 @@ systemctl enable debug-shell.service
|
||||
на +/bin/bash+.
|
||||
|
||||
\textbf{Совет:} Если вы не~можете воспользоваться командой +systemctl+
|
||||
(например, загрузились с помощью другой операционной системы), вы можете
|
||||
выполнить соответствующие действия и напрямую:
|
||||
(например, загрузились с помощью другой операционной системы),
|
||||
выполните соответствующие действия напрямую:
|
||||
\begin{Verbatim}
|
||||
cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
|
||||
mkdir -p sysinit.target.wants
|
||||
@@ -4759,6 +5055,7 @@ ln -s /lib/systemd/system/debug-shell.service sysinit.target.wants/
|
||||
\end{description}
|
||||
|
||||
\subsubsection{Если у вас есть доступ к оболочке}
|
||||
\label{sssec:kmsg}
|
||||
|
||||
Если вам все-таки удалось получить доступ к оболочке системы, вы можете
|
||||
воспользоваться ею для сбора диагностической информации. Загрузите систему со
|
||||
@@ -4833,7 +5130,9 @@ mount -o remount,ro /
|
||||
собрать диагностическую информацию другими методами (которые мы уже
|
||||
рассматривали применительно к проблемам загрузки):
|
||||
\begin{itemize}
|
||||
\item Используйте \hyperlink{it:serial}{последовательную консоль}.
|
||||
\item Используйте \hyperlink{it:serial}{последовательную
|
||||
консоль}\footnote{Прим. перев.: Здесь опять же стоит напомнить
|
||||
про +netconsole+ (см. примечание~\ref{ftn:netconsole}).}.
|
||||
\item Воспользуйтесь \hyperlink{it:dbgshell}{отладочной оболочкой}~---
|
||||
она полезна не~только на ранних стадиях загрузки, но и на
|
||||
поздних стадиях остановки системы.
|
||||
@@ -4883,7 +5182,7 @@ May 11 20:26:23 scratch foo[1329]: Failed to parse config
|
||||
|
||||
\subsection{Подготовка сообщений об ошибках}
|
||||
|
||||
Если вы собираетесь отправить сообщение об ошибке в systemd, пожалуйста,
|
||||
Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста,
|
||||
включите в него диагностическую информацию, в частности, содержимое системных
|
||||
журналов. Журналы должны быть полными (без вырезок), не~заархивированными, с
|
||||
MIME-типом +text/plain+.
|
||||
@@ -4925,6 +5224,142 @@ 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\footnote{Прим. перев.: Такое поведение
|
||||
задают разработчики дистрибутива, при помощи
|
||||
корректировки файла, содержащего стандартные функции для
|
||||
init-скриптов (например, +/etc/rc.d/init.d/functions+ в
|
||||
Fedora или +/etc/rc.status+ в openSUSE). Этот файл
|
||||
вызывается практически из всех init-скриптов в самом начале их
|
||||
работы.}.)
|
||||
\item Информация о зависимостях служб, прописанная в LSB-заголовке
|
||||
скрипта, играет существенную роль. Большинство реализаций SysV
|
||||
в различных дистрибутивах практически не~используют эту
|
||||
информацию, либо используют ее очень ограниченно. Вследствие
|
||||
этого, информацию о зависимостях часто указывали некорректно
|
||||
или не~полностью. В отличие от подобных реализаций, systemd
|
||||
интерпретирует эти заголовки корректно, и использует
|
||||
содержащуюся в них информацию при выполнении различных операций
|
||||
со службами (а не~только в момент их установки, как это делают
|
||||
некоторые другие реализации SysV\footnote{Прим. перев.:
|
||||
Например, +insserv+, используемый как дополнение к SysV init в
|
||||
Debian (а ранее и в openSUSE).}).
|
||||
\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+, +restart+, +reload+,
|
||||
+try-restart+, +force-reload+\footnote{Прим. перев.: Точный
|
||||
список <<стандартных>> команд для SysV init-скриптов зависит от
|
||||
используемого дистрибутива. Так уж исторически сложилось, что
|
||||
практически каждый дистрибутив использовал собственные стандарты
|
||||
интерфейсов SysV init. Это отразилось и на <<заглушках>>,
|
||||
используемых для обратной совместимости. Выше приведен список
|
||||
команд, которые поддерживаются как в Fedora, так и в openSUSE.})
|
||||
не~поддерживаются\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}>> с официального сайта проекта, по
|
||||
@@ -4952,7 +5387,7 @@ WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
|
||||
идентифицируются как раз по именам.
|
||||
|
||||
Существует несколько подходов к решению этой проблемы. В течение многих лет udev
|
||||
поддерживал механизм постоянной привязки имен к интерфейсам, на основе
|
||||
поддерживал механизм постоянной привязки имен к интерфейсам на основе
|
||||
MAC-адресов. Такой подход имел множество недостатков, в том числе: требование
|
||||
доступности корневого каталога на запись (что возможно далеко не~всегда);
|
||||
необходимость внесения изменений в образ системы после загрузки на новом
|
||||
@@ -4969,7 +5404,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
|
||||
{3e214} от 3 апреля 2012 года, в котором, среди прочего, был удален каталог
|
||||
+src/udev/src/rule_generator+.}.
|
||||
|
||||
Другая попытка решения обсуждаемой проблемы~--- +biosdevname+, программа,
|
||||
Другая попытка решения обсуждаемой проблемы~--- biosdevname, программа,
|
||||
формирующая имена интерфейсов на основании их физического расположении на
|
||||
материнской плате. Соответствующая информация запрашивается у BIOS. В чем-то
|
||||
такая схема похожа на ту, которую udev уже давно использует для формирования
|
||||
@@ -4998,24 +5433,25 @@ systemd/udev\footnote{Прим. перев.: См. коммит
|
||||
различных механизмов именования сетевых интерфейсов, получив в итоге схему,
|
||||
похожую на biosdevname, но отличающуюся большей гибкостью и максимально
|
||||
приближенную к алгоритмам идентификации устройств, используемым в ядре.
|
||||
В частности, udev теперь штатно поддерживает следующие механизмы именования
|
||||
В частности, 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 при именовании сетевых интерфейсов последовательно
|
||||
пытается применить схемы 1--3 (для первых двух требуется информация от
|
||||
EFI/BIOS). Если ни одна из них не~подходит, используется схема 5. Что касается
|
||||
прошивки). Если ни одна из них не~подходит, используется схема 5. Что касается
|
||||
схемы 4~--- она не~задействована по умолчанию, однако ее можно включить вручную.
|
||||
|
||||
Вышеописанная комбинированная схема используется лишь \emph{в последнюю
|
||||
@@ -5025,7 +5461,7 @@ EFI/BIOS). Если ни одна из них не~подходит, испол
|
||||
|
||||
\subsection{Еще раз, что здесь хорошего?}
|
||||
|
||||
С нашей новой схемой вы получаете:
|
||||
Достоинства нашей новой схемы:
|
||||
\begin{itemize}
|
||||
\item Имена интерфейсов остаются неизменными после перезагрузок.
|
||||
\item Имена интерфейсов остаются неизменными при добавлении или
|
||||
@@ -5041,13 +5477,13 @@ EFI/BIOS). Если ни одна из них не~подходит, испол
|
||||
устройство.
|
||||
\item Изменения в аппаратной конфигурации не~приводят к необходимости
|
||||
записи в каталог +/etc+.
|
||||
\item Полная поддержка системам, корень которых доступен только
|
||||
\item Полная поддержка систем, корень которых доступен только
|
||||
для чтения.
|
||||
\item Схема именования аналогичная той, которая используется
|
||||
\item Логика именования аналогична той, которая используется
|
||||
udev для формирования стабильных символьных ссылок в каталоге
|
||||
+/dev+ (+by-path+).
|
||||
\item Работает как на x86, так и на~других архитектурах.
|
||||
\item Работает одинаково во всех дистрибутивах, использующих на
|
||||
\item Работает одинаково во всех дистрибутивах, использующих
|
||||
systemd/udev.
|
||||
\item От этой схемы очень легко отказаться (см. ниже).
|
||||
\end{itemize}
|
||||
@@ -5095,8 +5531,8 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
|
||||
|
||||
\begin{Verbatim}
|
||||
Предсказуемые имена сетевых интерфейсов формируются на основании:
|
||||
- индексов встроенных в материнскую плату устройств (по информации EFI/BIOS)
|
||||
- индексов hotplug-слотов PCI-E (по информации EFI/BIOS)
|
||||
- индексов встроенных в материнскую плату устройств (по информации от прошивки)
|
||||
- индексов hotplug-слотов PCI-E (по информации от прошивки)
|
||||
- физического расположения точки подключения оборудования
|
||||
- MAC-адресов
|
||||
|
||||
@@ -5124,7 +5560,7 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
|
||||
|
||||
Примеры:
|
||||
|
||||
Подключенная к PCI сетевая карта, которая идентифцироуется прошивкой
|
||||
Подключенная к PCI сетевая карта, которая идентифицируется прошивкой
|
||||
по индексу "1":
|
||||
ID_NET_NAME_ONBOARD=eno1
|
||||
ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1
|
||||
@@ -5164,48 +5600,50 @@ 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. У вас могут возникнуть
|
||||
вопросы: <<Как их убрать?>> или <<Как задать для них параметры монтирования?>>.}
|
||||
\yousaywtfsk{Итак, вы запустили программу mount(8), и увидели в ее выводе
|
||||
множество странных файловых систем, не~указанных в /etc/fstab. У вас могут
|
||||
возникнуть вопросы: <<Как их убрать?>> или <<Как задать для них параметры
|
||||
монтирования?>>.}
|
||||
|
||||
В Linux предусмотрено несколько способов взаимодействия программ из пространства
|
||||
пользователя с ядром. Наиболее популярными механизмами являются системные вызовы
|
||||
(syscall), интерфейсы Netlink, а также виртуальные файловые системы (ФС), такие,
|
||||
как +/proc+ и +/sys+. Подобные ФС являются лишь программными интерфейсами, и
|
||||
не~предоставляют возможности для долговременного хранения данных (в частности,
|
||||
между перезагрузками системы). Они просто используют классические механизмы
|
||||
работы с файлами для предоставления доступа к различным данным и настройкам.
|
||||
Кроме того, существуют специальные ФС, используемые программами для собственных
|
||||
нужд, в частности, для хранения сегментов разделяемой памяти (shared memory),
|
||||
временных файлов и сокетов. В данной статье мы обсудим все эти разновидности
|
||||
не~обеспечивают долговременного хранения данных (в частности, между
|
||||
перезагрузками системы). Они просто используют классические механизмы работы с
|
||||
файлами для предоставления доступа к различным данным и настройкам. Кроме того,
|
||||
существуют специальные ФС, используемые программами для собственных нужд, в
|
||||
частности, для хранения сегментов разделяемой памяти (shared memory), временных
|
||||
файлов и сокетов. В данной статье мы обсудим все эти разновидности
|
||||
\emph{специальных файловых систем}. Ниже представлен список таких ФС,
|
||||
поддерживаемых в типовых Linux-системах:
|
||||
\begin{itemize}
|
||||
\item +/sys+ предоставляет доступ к драйверам и устройствам, а также
|
||||
некоторым другим параметрам ядра
|
||||
\item +/proc+ дает доступ к информации о выполняемых процессах,
|
||||
настройкам ядра, а также другим параметрам
|
||||
\item +/dev+ отображает файлы устройств (device nodes)
|
||||
\item +/run+ содержит файлы и сокеты, используемые программами
|
||||
\item +/tmp+ хранит временные и часто изменяемые объекты (X)
|
||||
некоторым другим параметрам ядра;
|
||||
\item +/proc+ дает доступ к информации о выполняемых процессах,
|
||||
настройкам ядра, а также другим параметрам;
|
||||
\item +/dev+ отображает файлы устройств (device nodes);
|
||||
\item +/run+ содержит файлы и сокеты, используемые программами;
|
||||
\item +/tmp+ хранит временные и часто изменяемые объекты (X);
|
||||
\item +/sys/fs/cgroup+ (и другие файловые системы, смонтированные в
|
||||
подкаталогах этого каталога) позволяют работать с иерархией
|
||||
контрольных групп
|
||||
контрольных групп;
|
||||
\item +/sys/kernel/security+, +/sys/kernel/debug+ (X),
|
||||
+/sys/kernel/config+ (X) предоставляют доступ к
|
||||
специализированным механизмам ядра
|
||||
\item +/sys/fs/selinux+ используется для взаимодействия с SELinux
|
||||
\item +/dev/shm+ содержит объекты разделяемой памяти
|
||||
\item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам
|
||||
специализированным механизмам ядра;
|
||||
\item +/sys/fs/selinux+ используется для взаимодействия с SELinux;
|
||||
\item +/dev/shm+ содержит объекты разделяемой памяти;
|
||||
\item +/dev/pts+ обеспечивает доступ к псевдо-TTY устройствам;
|
||||
\item +/proc/sys/fs/binfmt_misc+ используется для регистрации в ядре
|
||||
дополнительных бинарных форматов (X)
|
||||
\item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X)
|
||||
дополнительных бинарных форматов (X);
|
||||
\item +/dev/mqueue+ содержит объекты IPC-механизма mqueue (X);
|
||||
\item +/dev/hugepages+ позволяет программам запрашивать выделение
|
||||
<<гигантских>> страниц памяти (X)
|
||||
<<гигантских>> страниц памяти (X);
|
||||
\item +/sys/fs/fuse/connections+ обеспечивает доступ к
|
||||
FUSE-соединениям (X)
|
||||
\item +/sys/firmware/efi/efivars+ предоставляет доступ к переменным EFI
|
||||
FUSE-соединениям (X);
|
||||
\item +/sys/firmware/efi/efivars+ предоставляет доступ к переменным EFI;
|
||||
\end{itemize}
|
||||
|
||||
systemd монтирует все эти файловые системы на ранних стадиях загрузки, даже если
|
||||
@@ -5228,20 +5666,20 @@ systemd монтирует все эти файловые системы на р
|
||||
укажете, будут автоматически применяться к соответствующим ФС. Проще говоря:
|
||||
если вам нужно изменить параметры монтирования для специальных ФС, просто
|
||||
добавьте их в +/etc/fstab+ с указанием соответствующих опций. Кроме параметров
|
||||
монтирования, так можно изменить и сам тип файловой системы. В частности, этот
|
||||
способ позволяет переключить +/tmp+ с +tmpfs+ на физический дисковый раздел.
|
||||
монтирования, так можно изменить и сам тип файловой системы (в частности,
|
||||
перенести +/tmp+ из +tmpfs+ на раздел физического диска).
|
||||
|
||||
Также вы можете полностью отключить монтирование некоторых (но не~всех)
|
||||
специальных систем, если это действительно необходимо. Отключаемые ФС в списке
|
||||
выше отмечены (X). Для их отключения, достаточно замаскировать соответствующий
|
||||
юнит:
|
||||
выше отмечены (X). Для их отключения, достаточно заблокировать (замаскировать)
|
||||
соответствующий юнит:
|
||||
\begin{Verbatim}
|
||||
systemctl mask dev-hugepages.mount
|
||||
\end{Verbatim}
|
||||
|
||||
В результате выполнения такой операции, соответствующая ФС больше не~будет
|
||||
монтироваться по умолчанию, начиная со следующей загрузки системы. О том, что
|
||||
такое маскировка юнита, вы можете прочитать в~главе~\ref{sec:off}.
|
||||
такое блокировка юнита, вы можете прочитать в~главе~\ref{sec:off}.
|
||||
|
||||
На всякий случай отметим, что применение к специальным ФС параметров монтирования,
|
||||
указанных в +/etc/fstab+, обеспечивается службой
|
||||
@@ -5272,8 +5710,9 @@ 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{Итак, ваша служба настроена на запуск только после достижения цели
|
||||
\yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели
|
||||
network.target, однако, несмотря на это, она все равно запускается до появления
|
||||
сети. У вас возникают вопросы: <<Почему так происходит?>> и <<Как это
|
||||
исправить?>>.}
|
||||
@@ -5281,8 +5720,8 @@ network.target, однако, несмотря на это, она все рав
|
||||
Цель +network.target+ является systemd-шным аналогом LSB-сущности (facility)
|
||||
\verb+$network+. Определение этой сущности в стандарте
|
||||
\href{http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html}%
|
||||
{довольно расплывчато} и оставляет широкий простор для трактовок. Вот примеры
|
||||
некоторых из них:
|
||||
{довольно расплывчато} и оставляет широкий простор для различных трактовок. Вот
|
||||
примеры некоторых из них:
|
||||
\begin{itemize}
|
||||
\item Все заданные в настройках сетевые интерфейсы переведены в состояние
|
||||
UP и получили IP-адреса.
|
||||
@@ -5290,7 +5729,7 @@ network.target, однако, несмотря на это, она все рав
|
||||
зарегистрирована несущая (link beat), получили IP-адреса.
|
||||
Наличие или отсутствие явных настроек роли не~играет.
|
||||
\item Доступен DNS-сервер.
|
||||
\item Доступен некоторый выбранный сервер.
|
||||
\item Доступна некоторая выбранная сетевая служба.
|
||||
\item Доступен некий абстрактный <<интернет>>.
|
||||
\item Все заданные в настройках ethernet-интерфейсы переведены в
|
||||
состояние UP, однако процесс настройки PPP-интерфейсов еще
|
||||
@@ -5298,7 +5737,7 @@ network.target, однако, несмотря на это, она все рав
|
||||
\item Активирован некий профиль сетевых настроек, задающий одно из
|
||||
условий выше. В разных профилях могут использоваться разные
|
||||
условия.
|
||||
\item Выполняется некоторое условие (выбор условия определяется
|
||||
\item Выполняется некоторый набор условий (выбор условий определяется
|
||||
физическим расположением системы).
|
||||
\item Настроен как минимум один глобальный адрес IPv4.
|
||||
\item Настроен как минимум один глобальный адрес IPv6.
|
||||
@@ -5381,11 +5820,8 @@ service-файл, запускающий любую заданную вами п
|
||||
всего указать здесь ту же самую +network.target+: в результате, ваша служба и
|
||||
+network.target+ будут взаимно зависеть друг от друга, но при этом
|
||||
+network.target+ будет активирована только после того, как отработает ваша
|
||||
служба. Разница между +WantedBy=+ и +RequiredBy=+ состоит в том, что при
|
||||
использовании Require требуется \emph{успешное} завершение запуска вашей службы.
|
||||
Если он завершится с ненулевым кодом выхода или по сигналу, +network.target+
|
||||
не~будет активирована. В то время как для Want достаточно просто завершения
|
||||
запуска, вне зависимости от успешности. В качестве основы вы можете взять
|
||||
служба (о разницы между +WantedBy=+ и +RequiredBy=+ см.
|
||||
примечание~\ref{ftn:wants}). В качестве основы вы можете взять
|
||||
\href{http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/NetworkManager-wait-online.service.in}%
|
||||
{апстримный файл} +NetworkManager-wait-online.service+. В завершение,
|
||||
не~забудьте выполнить для своей службы +systemctl enable+.}.
|
||||
@@ -5407,7 +5843,7 @@ service-файл, запускающий любую заданную вами п
|
||||
\item Отслеживайте изменений конфигурации сети при помощи
|
||||
\href{https://www.kernel.org/doc/man-pages/online/pages/man7/rtnetlink.7.html}%
|
||||
{rtnetlink} и реагируйте соответствующим образом. Это наиболее
|
||||
правильный, но далеко не~всегда простой способ.
|
||||
правильный, но далеко не~всегда самый простой способ.
|
||||
\item Если вы разрабатываете серверное приложение: слушайте только
|
||||
адреса 0.0.0.0 и 127.0.0.1. Оба этих псевдо-адреса должны быть
|
||||
доступны постоянно. Если ваша программа будет слушать только их,
|
||||
@@ -5425,11 +5861,12 @@ 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{Итак, у вас есть служба, которая требует приоритет реального времени
|
||||
\yousaywtf{Итак, у вас есть служба, которая требует приоритет реального времени
|
||||
(realtime). Однако, когда вы пытаетесь запустить ее на системе, работающей под
|
||||
управлением systemd, ваша служба не~может получить этот приоритет, хотя обладает
|
||||
всеми необходимыми для этого привилегиями. Вы хотите понять, почему это
|
||||
всеми необходимыми для этого привилегиями. Вы хотите понять, почему так
|
||||
происходит, и как это можно исправить.}
|
||||
|
||||
\subsection*{В чем же дело?}
|
||||
@@ -5445,7 +5882,7 @@ service-файл, запускающий любую заданную вами п
|
||||
существенный недостаток: она требует явного задания realtime-бюджета времени (RT
|
||||
budget) для своих контрольных групп. Если же бюджет группы не~задан, то ее
|
||||
процессы не~смогут получить приоритет реального времени (соответствующая
|
||||
операция будет завершаться с ошибкой +EPERM+~--- <<недостаточные полномочия>>).
|
||||
операция будет завершаться с ошибкой +EPERM+~--- <<недостаточно полномочий>>).
|
||||
systemd не~может присваивать такой бюджет \emph{каждой} группе, просто потому,
|
||||
что не~знает, как его правильно делить между ними. Бюджет выдается в абсолютных
|
||||
единицах времени, и их общее количество ограничено. Мы не~можем предложить
|
||||
@@ -5460,29 +5897,35 @@ systemd не~может присваивать такой бюджет \emph{к
|
||||
\item Можно просто отключить использование cpu-контроллера по умолчанию
|
||||
для системных служб. Для этого, задайте в файле
|
||||
+/etc/systemd/system.conf+ параметр +DefaultControllers=+ равным
|
||||
пустой строке, после чего перезагрузите систему. (Также вы
|
||||
пустой строке, после чего перезагрузите систему. (Либо вы
|
||||
можете отключить контроллер +cpu+ на этапе сборки ядра. systemd
|
||||
не~пытается использовать контроллеры, которые не~поддерживаются
|
||||
ядром.)
|
||||
\item Также вы можете отключить группировку по +cpu+ только для
|
||||
конкретных служб. Для этого отредактируйте конфигурацию службы,
|
||||
добавив параметр +ControlGroup=cpu:/+ в секцию +[Service]+. В
|
||||
добавив параметр
|
||||
\begin{Verbatim}
|
||||
ControlGroup=cpu:/
|
||||
\end{Verbatim}
|
||||
в секцию +[Service]+. В
|
||||
результате, процессы данной службы будут помещены не~в
|
||||
собственную контрольную группу (как это делалось по умолчанию),
|
||||
а в корневую контрольную группу иерархии +cpu+. Процессы из
|
||||
корневой группы располагают полным realtime-бюджетом.
|
||||
\item И наконец, вы можете явно выделить своей службе некоторый бюджет.
|
||||
Для этого добавьте в секцию +[Service]+ строку наподобие
|
||||
+ControlGroupAttribute=cpu.rt_runtime_us 500000+. Подробнее о
|
||||
правильном распределении бюджета читайте в
|
||||
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}%
|
||||
\begin{Verbatim}
|
||||
ControlGroupAttribute=cpu.rt_runtime_us 500000
|
||||
\end{Verbatim}
|
||||
Подробнее о правильном распределении бюджета читайте в
|
||||
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt}%
|
||||
{документации к ядру}.
|
||||
\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