diff --git a/s4a.tex b/s4a.tex index 6cee031..2ebe533 100644 --- a/s4a.tex +++ b/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[Проверка параметров ядра] Для корректной загрузки системы необходимо,