Добавлено примечание об устаревании resource-control

s4a.tex

@@ -3958,7 +3958,27 @@ Resource Limits}.
 В этой статье я попробую рассказать о методах управления механизмами
 распределения ресурсов между службами systemd. Эта функциональность присутствует
 в systemd уже долгое время, и давно пора рассказать о ней пользователям и
-администраторам.
+администраторам\footnote{Прим. перев.: Дальнейшее содержимое этой главы
+устарело и сохраняется лишь из исторических соображений (ну и для тех, кто
+администрирует системы со старыми версиями ядра и systemd). Практически все
+описанные в ней настройки объявлены устаревшими в ходе миграции с
+\href{https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt}{cgroup v1}
+на \href{https://www.kernel.org/doc/Documentation/cgroup-v2.txt}{cgroup v2},
+произведенной в версиях 230--232. В частности, директива +CPUShares=+
+заменена на +CPUWeight=+, +MemoryLimit=+~--- на +MemoryMax=+,
++BlockIOWeight=+~--- на +IOWeight=+/+IODeviceWeight=+,
++BlockIOReadBandwidth=+~--- на +IOReadBandwidthMax=+ и т.д. Смысл остается 
+тем же, поменялись лишь некоторые тонкости, связанные с работой cgroups.
+Например, допустимые значения для +CPUShares+ лежали в диапазоне от 2 до 262144,
+а для +BlockIOWeight+~--- от 10 до 1000, в то время как новые <<весовые>>
+настройки имеют стандартный диапазон 1--10000. Также, добавлены новые настройки,
+например, +CPUQuota=+ для деления процессора по долям, +MemorySwapMax=+ для
+ограничения использования подкачки. В любом случае, лучше внимательно
+ознакомиться с актуальной версией страницы руководства
+\href{https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
+{systemd.resource-control(5)}. Кстати, используемый в статье механизм директив
++.include+ тоже устарел~--- вместо них нужно использовать фрагменты конфигов
+(см. прим.~\ref{ftn:frag}).}.
 
 В свое время я
 \href{http://0pointer.de/blog/projects/cgroups-vs-cgroups.html}{пояснял}%
@@ -4037,31 +4057,32 @@ CPUShares=1500
 умолчанию, сделанными разработчиками Apache или его сопровождающими в вашем
 дистрибутиве (если это включение не~указать явно, данный файл будет
 проигнорирован).  Далее, мы указываем тот параметр, который хотим
-изменить\footnote{Прим. перев.: В новых версиях systemd, начиная со 198, можно
-поступить проще: вместо того, чтобы создавать свой юнит-файл в каталоге +/etc+ и
-включать в него содержимое штатного (из +/usr+), достаточно просто создать
-каталог +/etc/systemd/system/httpd.service.d/+ и поместить в него файл
-+my_resource_limit.conf+ (суффикс +.conf+ обязателен), в котором указываются
-только те настройки, которые необходимо изменить (последние две строки
-вышеприведенного листинга). Это никак не~отменяет основного конфигурационного
-файла юнита (который может находиться в +/usr+ или +/etc+), однако настройки из
-+.d+-каталогов имеют более высокий приоритет и могут перекрывать настройки
-основного файла. Все вышесказанное относится и к другим примерам из этого
-раздела.}. Сохраняем файл, приказываем systemd перечитать конфигурацию, и
-перезапускаем Apache, чтобы настройки вступили в силу\footnote{Прим. перев.:
-systemd версий до 197 (включительно) не~имел штатного механизма для изменения
-параметров контрольных групп <<на лету>> (без перезапуска службы). Если у вас
-все же возникнет такая необходимость, вы можете узнать контрольную группу службы
-командой +systemctl show -p ControlGroup имя_службы.service+, и выполнить
-требуемые настройки напрямую через запись значений в псевдофайлы cgroupfs
-(разумеется, при следующем запуске службы к ней будут применены параметры,
-указанные в конфигурационном файле). В версиях systemd со 198 по 204, 
-программа +systemctl+ поддерживала команды +set-cgroup-attr+,
-+unset-cgroup-attr+ и +get-cgroup-attr+, позволявшие манипулировать настройками
-контрольных групп. Начиная с systemd 205, они были заменены командой
-+set-property+, работающей с параметрами конфигурации юнитов. Установленные
-через +systemctl+ настройки сохраняются во вспомогательных конфигурационных
-файлах, которые размещаются в +.d+-каталогах (см. примечание выше).}:
+изменить\footnote{\label{ftn:frag}Прим. перев.: В новых версиях systemd, начиная
+со 198, можно поступить проще: вместо того, чтобы создавать свой юнит-файл в
+каталоге +/etc+ и включать в него содержимое штатного (из +/usr+), достаточно
+просто создать каталог +/etc/systemd/system/httpd.service.d/+ и поместить в него
+файл +my_resource_limit.conf+ (суффикс +.conf+ обязателен), в котором
+указываются только те настройки, которые необходимо изменить (последние две
+строки вышеприведенного листинга). Это никак не~отменяет основного
+конфигурационного файла юнита (который может находиться в +/usr+ или +/etc+),
+однако настройки из +.d+-каталогов имеют более высокий приоритет и могут
+перекрывать настройки основного файла. Все вышесказанное относится и к другим
+примерам из этого раздела.}. Сохраняем файл, приказываем systemd перечитать
+конфигурацию, и перезапускаем Apache, чтобы настройки вступили в
+силу\footnote{Прим. перев.: systemd версий до 197 (включительно) не~имел
+штатного механизма для изменения параметров контрольных групп <<на лету>> (без
+перезапуска службы). Если у вас все же возникнет такая необходимость, вы можете
+узнать контрольную группу службы командой 
++systemctl show -p ControlGroup имя_службы.service+, и выполнить требуемые
+настройки напрямую через запись значений в псевдофайлы cgroupfs (разумеется, при
+следующем запуске службы к ней будут применены параметры, указанные в
+конфигурационном файле). В версиях systemd со 198 по 204, программа +systemctl+
+поддерживала команды +set-cgroup-attr+, +unset-cgroup-attr+ и +get-cgroup-attr+,
+позволявшие манипулировать настройками контрольных групп. Начиная с systemd 205,
+они были заменены командой +set-property+, работающей с параметрами конфигурации
+юнитов.  Установленные через +systemctl+ настройки сохраняются во
+вспомогательных конфигурационных файлах, которые размещаются в +.d+-каталогах
+(см. примечание выше).}:
 \begin{Verbatim}
 systemctl daemon-reload
 systemctl restart httpd.service
@@ -5727,7 +5748,7 @@ exit
 		уничтожается после завершения конвейера):
 		\begin{Verbatim}
 # cat some-file.txt | systemd-run --pipe --property=DynamicUser=1 sort -u | \
-	grep -i foobar > some-other-file.txt
+        grep -i foobar > some-other-file.txt
 		\end{Verbatim}
 	\item Сочетая технологию динамических пользователей и экземпляров
 		служб\footnote{Прим перев.: Более подробно работа с экземплярами
@@ -6980,7 +7001,7 @@ systemctl --root=/ enable debug-shell.service
 	+debug-shell.service+\footnote{Прим. перев.: Надо полагать, речь идет о
 	чем-то вроде <<\texttt{systemctl add-wants kbrequest.target
 	debug-shell.service}>>.}~--- тогда отладочная оболочка будет запускаться
-	по запросу (ALT–$\uparrow$ из tty). Указанные проблемы с безопасностью
+	по запросу (ALT--$\uparrow$ из tty). Указанные проблемы с безопасностью
 	при этом остаются, но оболочка хотя бы не~будет работать постоянно.
 
 \item[Проверка параметров ядра] Для корректной загрузки системы необходимо,