13 Отчет о состоянии службы и ее журнал



Pdf просмотр
страница12/12
Дата09.11.2016
Размер5.01 Kb.
Просмотров3089
Скачиваний0
1   ...   4   5   6   7   8   9   10   11   12
-- для устройств, встроенных в материнскую плату s[f][d] -- для hotplug-слотов x -- при именовании по MAC-адресу
[P]ps[f][d] -- на основании физического расположения PCI-устройства
[P]ps[f][u
][..][c][i]
-- идентификационная цепочка для USB-устройств
Все многофункциональные (multi-function) PCI-устройства содержат в своем имени номер функции "f" (отсчитываются от нуля).
При именовании по расположению устройства, индекс PCI-домена "P"
указывается только в том случае, если он отличен от нулевого.
Для USB-устройства формируется полная цепочка номеров портов хабов, через которые оно подключено. Если итоговая строка будет длиннее 15 символов, она не экспортируется.
Стандартные значения config == 1 и interface == 0 опускаются.
Примеры:
Подключенная к PCI сетевая карта, которая идентифицируется прошивкой по индексу "1":
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1
Сетевая карта, включенная в hotplug PCI-слот, который идентифицируется прошивкой:
/sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1
ID_NET_NAME_MAC=enx000000000466
ID_NET_NAME_PATH=enp5s0
ID_NET_NAME_SLOT=ens1
Multi-function PCI устройство с двумя портами:
/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0
ID_NET_NAME_MAC=enx78e7d1ea46da
ID_NET_NAME_PATH=enp2s0f0
/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1
ID_NET_NAME_MAC=enx78e7d1ea46dc
ID_NET_NAME_PATH=enp2s0f1
Подключенная к PCI WLAN-карта:
99

/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0
ID_NET_NAME_MAC=wlx0024d7e31130
ID_NET_NAME_PATH=wlp3s0
Встроенный USB 3G модем:
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6
ID_NET_NAME_MAC=wwx028037ec0200
ID_NET_NAME_PATH=wwp0s29u1u4i6
Подключенный по USB Android-смартфон:
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2
ID_NET_NAME_MAC=enxd626b3450fb5
ID_NET_NAME_PATH=enp0s29u1u2
E
Специальные файловые системы
128
Итак, вы запустили программу mount(8), и увидели в ее выводе множество стран- ных файловых систем, не указанных в /etc/fstab. У вас могут возникнуть вопросы:
«Как от них избавиться?» или «Как задать для них параметры монтирования?».
В Linux предусмотрено несколько способов взаимодействия программ из простран- ства пользователя с ядром. Наиболее популярными механизмами являются системные вызовы (syscall), интерфейсы Netlink, а также виртуальные файловые системы (ФС),
такие, как /proc и /sys. Подобные ФС являются лишь программными интерфейсами, и не обеспечивают долговременного хранения данных (в частности, между перезагрузка- ми системы). Они просто используют классические механизмы работы с файлами для предоставления доступа к различным данным и настройкам. Кроме того, существуют специальные ФС, используемые программами для собственных нужд, в частности, для хранения сегментов разделяемой памяти (shared memory), временных файлов и сокетов.
В данной статье мы обсудим все эти разновидности специальных файловых систем. Ни- же представлен список таких ФС, поддерживаемых в типовых Linux-системах:
∙ /sys предоставляет доступ к драйверам и устройствам, а также некоторым другим параметрам ядра;
∙ /proc дает доступ к информации о выполняемых процессах, настройкам ядра, а также другим параметрам;
∙ /dev отображает файлы устройств (device nodes);
∙ /run содержит файлы и сокеты, используемые программами;
∙ /tmp хранит временные и часто изменяемые объекты (X);
∙ /sys/fs/cgroup (и другие файловые системы, смонтированные в подкаталогах это- го каталога) позволяют работать с иерархией контрольных групп;
∙ /sys/kernel/security, /sys/kernel/debug (X), /sys/kernel/config (X) предо- ставляют доступ к специализированным механизмам ядра;
∙ /sys/fs/selinux используется для взаимодействия с SELinux;
∙ /dev/shm содержит объекты разделяемой памяти;
∙ /dev/pts обеспечивает доступ к псевдо-TTY устройствам;
∙ /proc/sys/fs/binfmt_misc используется для регистрации в ядре дополнительных бинарных форматов (X);
128
Прим. перев.: Перевод статьи «
API File Systems
» с официального сайта проекта, по состоянию на
2013-05-26 08:37:25 (коммит 6a93f).
100

∙ /dev/mqueue содержит объекты IPC-механизма mqueue (X);
∙ /dev/hugepages позволяет программам запрашивать выделение «гигантских»
страниц памяти (X);
∙ /sys/fs/fuse/connections обеспечивает доступ к FUSE-соединениям (X);
∙ /sys/firmware/efi/efivars предоставляет доступ к переменным EFI;
systemd монтирует все эти файловые системы на ранних стадиях загрузки, даже если они не указаны явно в /etc/fstab. В зависимости от настроек вашего ядра, некоторые из перечисленных выше ФС могут быть недоступны, и наоборот, могут присутствовать другие специальные ФС, не приведенные в этом списке. Все эти механизмы играют важную роль во взаимодействии ядра с программами и программ между собой. Именно поэтому они подключаются автоматически, безо всякого участия пользователя. Необ- думанное вмешательство в их работу (отключение или изменение параметров) может нарушить нормальную работу ваших программ, так как они утратят доступ к необхо- димым для них интерфейсам.
В абсолютном большинстве случаев достаточно настроек, используемых по умолча- нию. Однако, могут возникнуть ситуации, когда необходимо изменить параметры мон- тирования специальных ФС, либо полностью отключить монтирование некоторых из них.
Несмотря на то, что эти ФС по умолчанию отсутствуют в /etc/fstab, ничто не ме- шает вам их туда добавить. Параметры монтирования, которые вы при этом укажете,
будут автоматически применяться к соответствующим ФС. Проще говоря: если вам нужно изменить параметры монтирования для специальных ФС, просто добавьте их в
/etc/fstab с указанием соответствующих опций. Кроме параметров монтирования, так можно изменить и сам тип файловой системы (в частности, перенести /tmp из tmpfs на раздел физического диска).
Также вы можете полностью отключить монтирование некоторых (но не всех) спе- циальных систем, если это действительно необходимо. Отключаемые ФС в списке выше отмечены (X). Для их отключения, достаточно заблокировать (замаскировать) соответ- ствующий юнит:
systemctl mask dev-hugepages.mount
В результате выполнения такой операции, соответствующая ФС больше не будет монтироваться по умолчанию, начиная со следующей загрузки системы. О том, что такое блокировка юнита, вы можете прочитать в главе
5
На всякий случай отметим, что применение к специальным ФС параметров монтиро- вания, указанных в /etc/fstab, обеспечивается службой systemd-remount-fs.service
Зачем вы мне все это рассказываете? Я просто хочу убрать tmpfs из /tmp!
У вас есть три варианта:
1. Вы можете отключить любое монтирование в /tmp, в результате чего содержимое данного каталога будет храниться на том же разделе, что и корень. Для этого достаточно выполнить команду systemctl mask tmp.mount
2. Вы можете смонтировать в /tmp обычную файловую систему, размещенную на диске. Для этого достаточно создать соответствующую запись в /etc/fstab.
3. Если вы хотите оставить в /tmp tmpfs, но при этом задать для нее другой раз- мер — это тоже делается через внесение в /etc/fstab соответствующей записи,
предписывающей монтирование tmpfs в /tmp с нужным вам значением параметра size=.
101

F
Запуск служб после появления сети
129
Итак, ваша служба настроена на запуск только после достижения цели network.target, однако, несмотря на это, она все равно запускается до появления се- ти. У вас возникают вопросы: «Почему так происходит?» и «Как это исправить?».
В некоторых LSB-совместимых скриптах инициализации, при описания зависимо- стей используется сущность (facility) $network. Определение этой сущности в стандарте довольно расплывчато и оставляет широкий простор для различных трактовок. Вот примеры некоторых из них:
∙ Запущен демон управления сетью (например, NetworkManager или systemd- networkd).
∙ Все заданные в настройках сетевые интерфейсы переведены в состояние UP и получили IP-адреса.
∙ Все имеющиеся физические сетевые интерфейсы, на которых зарегистрирована несущая (link beat), получили IP-адреса. Наличие или отсутствие явных настроек роли не играет.
∙ Доступен DNS-сервер.
∙ Доступна некоторая выбранная сетевая служба.
∙ Доступен некий абстрактный «интернет».
∙ Все заданные в настройках ethernet-интерфейсы переведены в состояние UP, од- нако процесс настройки PPP-интерфейсов еще не начался.
∙ Активирован некий профиль сетевых настроек, задающий одно из условий выше.
В разных профилях могут использоваться разные условия.
∙ Выполняется некоторый набор условий (выбор условий определяется физическим расположением системы).
∙ Настроен как минимум один глобальный адрес IPv4.
∙ Настроен как минимум один глобальный адрес IPv6.
∙ Настроен как минимум один глобальный адрес IPv4 или IPv6.
Этот список можно продолжать и дальше. Каждый предложенный в нем вариант можно использовать в качестве критерия появления сети, однако ни один из них не под- ходит в качестве варианта по умолчанию, пригодного для абсолютного большинства задач.
Современные компьютерные сети живут в очень динамичном ритме: компьютеры перемещаются между сетями, сетевые настройки меняются, устройства подключаются и отключаются, виртуальные сети настраиваются, перенастраиваются и выключаются.
Наличие сетевого соединения не является чем-то постоянным и безусловным. В разные моменты времени компьютер может быть подключен к разным сетям. И это справедли- во не только для мобильных устройств (смартфонов, планшетов и ноутбуков), но и, в определенной мере, для встраиваемых и серверных систем. Программы, которые счита- ют, что сеть является чем-то неизменным и непрерывно доступным, не могут нормально функционировать в таких условиях. Хорошо написанная программа должна корректно реагировать на изменение состояния сети, и не унывать в беде. Если нужный ей сер- вер не доступен в настоящий момент, она должна не зависать по тайм-ауту, а пытаться достучаться к нему снова и снова. Если сетевое соединение утрачено, она должна отре- агировать на это. Реализовать такое реагирование в коде демона, на самом деле, не так уж и сложно. Существует множество хорошо известных сетевых служб, которые уже
129
Прим. перев.: Перевод статьи «
Running Services After the Network is up
» с официального сайта проекта, по состоянию на 2014-06-11 13:22:03 (коммит 0ff8f).
102
давно поддерживают такую возможность. Подобные службы можно запускать в любой момент, они устойчивы к сбоям, и работают корректно во всех возможных ситуациях.
$network предназначена для поддержки программ, созданных в предположении, что сеть доступна постоянно (т.е. написанных не очень аккуратно). Конкретные требования таких программ могут сильно отличаться. Например, IMAP-серверу будет достаточно наличия IP-адреса, на котором можно слушать. В то время как для клиентов сете- вых файловых систем требуется требуется доступность и работоспособность сервера, а также, опционально, наличие работоспособного DNS. Таким образом, конкретные тре- бования к $network сильно зависят от решаемой задачи.
По соображениям надежности, загрузка системы не должна зависеть от второсте- пенных служб. В частности, отсутствие ответа от DHCP-сервера не должно завешивать процесс загрузки системы (за исключением ситуаций, когда сетевое соединение действи- тельно необходимо для работы системы, например, при загрузке по сети).
F.1
Как это реализовано в systemd
В systemd существует сразу три юнита (целевых состояния, target units), в совокуп- ности берущих на себя роль LSB-сущности $network
130
:
∙ network.target не играет существенной роли в процессе загрузки системы. Ак- тивация данного целевого состояния лишь показывает, что программа управле- ния сетью была запущена. А вот будет ли к этому моменту настроена сеть —
не регламентируется. Основное назначение данного юнита — синхронизация опе- раций при остановке системы. Так как порядок остановки юнитов обратен по- рядку их запуска, все юниты, в описании которых указано After=network.target,
при выключении системы будут остановлены до того, как отключится сеть. Это позволит программам корректно закрывать все сетевые соединения, а не остав- лять их «повисшими». Обратите внимание, что network.target является пассив- ным юнитом: вы не можете запустить его ни вручную (через systemctl start),
ни через зависимости своих служб (Wants и Requires). Активацией и деак- тивацией данного юнита занимается программа, управляющая сетью в вашей системе. В юнит-файлах служб, использующих сеть, целесообразно указывать
After=network.target, но ни в коем случае не Wants=network.target, и уж тем более не Requires=network.target
131
∙ network-online.target активируется только после появления сети. Трактовка по- нятия «появилась сеть» остается на совести разработчиков программы, управля- ющей сетью
132
. Обычно оно подразумевает, что одному или нескольким сетевым интерфейсам присвоены маршрутизируемые IP-адреса. Основная задача обсужда- емого юнита — обеспечить задержку запуска отдельных служб до того момента,
как появится сеть. Данный юнит является активным, т.е. его можно указывать в
130
Прим. перев.: Приведенные здесь сведения применимы только к systemd версий 213 и выше, в которых появился юнит network-online.target. О том, как сущность $network работала в предыдущих версиях systemd, желающие могут прочитать в примечании
134 131
Прим. перев.: Концепция активных и пассивных юнитов более подробно пояснена на странице руко- водства systemd.special(7)
. Она описывает взаимосвязь двух классов служб: потребители (consumers)
и поставщики (providers). Например, служба управления сетью является поставщиком (сети), а демон торрент-клиента — потребителем. Синхронизация между ними может осуществляться посредством как пассивных, так и активных целевых состояний. Разница между активными и пассивными целевыми юнитами состоит в том, что для активных целей Requires/Wants зависимости прописываются в юнит- файле службы-потребителя, а для пассивных — в юнит-файле службы-поставщика. Никакой магии здесь нет — это просто соглашение между авторами юнит-файлов. В рамках этого же принципа, в конфигурационные файлы пассивных юнитов добавляется директива RefuseManualStart=yes, запреща- ющая их активацию «вручную».
132
Прим. перев.: Определением момента готовности сети обычно занимается отдельная утилита.
В NetworkManager это nm-online, в systemd-networkd —
systemd-networkd-wait-online(8)
. В случае
NM, сеть считается готовой после появления на любом из управляемых им устройств корректного
IP-адреса (глобального или локального), в случае networkd — после того, как для всех интерфейсов,
прописанных в его конфигурации, завершится процесс настройки (успешно или с ошибкой), причем как минимум для одного интерфейса настройка должна завершиться успешно.
103
зависимостях служб, которым необходима запущенная сеть (и, в то же время, нель- зя указывать в зависимостях у самой службы управления сетью). По умолчанию,
этот юнит автоматически прописывается в зависимости к точкам монтирования всех удаленных файловых систем (например, NFS, SMBFS/CIFS), приведенным в файле /etc/fstab. Таким образом, монтирование этих файловых систем начнет- ся только после того, как появится сеть. Однако, если таких точек монтирования не указано, а также отсутствуют службы, явно требующие по зависимостям дан- ный юнит, он вообще не активируется в процессе загрузки системы, что позволяет избежать нежелательных задержек в случае проблем с сетью. Настоятельно реко- мендуется не злоупотреблять зависимостями от этого юнита. В частности, для сер- верных приложений, как правило, такая зависимость избыточна (обычно, сервер может работать даже в отсутствие внешней сети, обслуживая локальные соедине- ния). Основная задача обсуждаемого юнита — своевременный запуск клиентских программ, которые не могут работать без сети.
∙ network-pre.target
133
активируется до того, как начнется настройка сетевых интерфейсов. Основная функция этого юнита — своевременный запуск служб,
выполняющих настройку брандмауэра. Таким образом, к моменту появления сети брандмауэр будет уже готов к отражению возможных атак. Указанный юнит является пассивным — вы не можете запустить его вручную, и его нель- зя указывать в качестве Requires/Wants-зависимости в юнит-файлах службы управления сетью. Напротив, такие зависимости должны прописываться у тех служб, которые должны быть запущены до появления сети. В юнит-файле службы управления сетью целесообразно указать After=network-pre.target, но не Wants=network-pre.target/Requires=network-pre.target. В то же время, в юнит-файлах служб, которые должны быть запущены до появления сети (напри- мер, уже обсуждавшиеся выше службы брандмауэра), наоборот, рекомендуется указывать Before=network-pre.target и Wants=network-pre.target. Таким об- разом, данное целевое состояние будет активироваться в нужный момент только в том случае, если у какой-либо из ваших служб действительно имеется такая зависимость. Если же подобных служб нет, network-pre.target не будет активи- роваться вообще.
Когда systemd встречает в
LSB-заголовках init-скриптов зависимость
$network, он преобразовывает ее в зависимости Wants=network-online.target и
After=network-online.target, что позволяет обеспечить поведение, более или менее соответствующее требованиям LSB
134
За дальнейшими подробностями вы можете обратиться к странице руководства systemd.special(7)
F.2
Короче, как заставить network.target работать?
Это зависит от конфигурации вашей системы и конкретных требований ваших служб
(см. выше). Многие службы управления сетью предоставляют возможность принуди- тельной активации network-online.target, в результате чего network.target по свое- му эффекту становится практически эквивалентной network-online.target.
133
Прим. перев.: Поддержка данного юнита добавлена в systemd-networkd начиная с systemd 214.
Тогда же в официальной документации появились первые упоминания о нем. Однако, ничто не мешает использовать этот юнит и в более ранних версиях systemd — достаточно скопировать соответствующий конфигурационный файл в каталог /etc/systemd/system.
134
Прим. перев.: Трансляция LSB-сущности $network в network-online.target введена в systemd начи- ная с systemd 213. В systemd версий до 212 включительно, $network транслировалась в network.target.
Что приводило к довольно неожиданным эффектам — как уже упоминалось выше, активация network.target вовсе не означает, что сеть уже настроена. В связи с этим, официальная доку- ментация рекомендовала привязывать network.target к моменту запуска сети, например, через
NetworkManager-wait-online.service. Соответствующие команды приведены чуть ниже по тексту. Они действуют даже в новых версиях systemd, но особого смысла уже не несут — задача синхронизации ре- шается юнитом network-online.target, который в случае необходимости активируется автоматически
(реализовано в юнит-файлах systemd-networkd 213 и выше, NetworkManager 0.9.9.95 и выше).
104

Если вы используете NetworkManager, вы можете задействовать специальную служ- бу NetworkManager-wait-online.service:
systemctl enable NetworkManager-wait-online.service
Если же вы используете systemd-networkd, соответствующая служба будет называть- ся systemd-networkd-wait-online.service:
systemctl enable systemd-networkd-wait-online.service
Включение такой службы позволит гарантировать, что загрузка продолжится толь- ко после того, как все заданные в настройках сетевые интерфейсы будут переведены в состояние UP и получат IP-адреса. Максимальное время ожидания — 90 секунд
135
Обратите внимание, что включение подобных служб может сильно замедлить загрузку.
Обе эти службы по умолчанию отключены
136
Как альтернативный вариант, вы можете поменять непосредственно юнит-файл той службы, которая нуждается в сети, добавив туда опции After=network-online.target и Wants=network-online.target
137
F.3
А что делать нам, разработчикам?
Если вы — не администратор, а разработчик сетевой службы, то вам стоит задумать- ся не о том, что делать с network.target, а о том, как можно исправить вашу службу,
чтобы она нормально реагировала на изменение состояния сети. Это позволит порадо- вать ваших пользователей (когда программа работает без дополнительной возни — это не может не радовать), а также уменьшит количество сообщений об ошибках (так как ваша программа уже не будет паниковать по пустякам). Кроме того, системы ваших пользователей будут грузиться быстрее, потому что их уже не будет задерживать необ- ходимость ожидать появления сети (в случае с медленным DHCP-сервером, прогресс может быть весьма ощутимым).
Можно предложить несколько подходов к решению этой задачи:
∙ Отслеживайте изменений конфигурации сети при помощи rtnetlink и реагируйте соответствующим образом. Это наиболее правильный, но далеко не всегда самый простой способ.
∙ Если вы разрабатываете серверное приложение: слушайте только адреса [::], [::1],
0.0.0.0 и 127.0.0.1. Все эти псевдо-адреса должны быть доступны постоянно. Если ваша программа будет слушать только их, ей будут глубоко безразличны измене- ния конфигурации сети.
∙ Если вы разрабатываете серверное приложение и вам нужно слушать некий задан- ный адрес: воспользуйтесь опцией
IP_FREEBIND
, доступной на Linux-системах.
Она позволит вашей программе слушать даже те адреса, которые не присвоены ло- кальным сетевым интерфейсам (в данный момент или вообще), что также сделает ваш код устойчивым к изменению сетевой конфигурации.
135
Прим. перев.: У NetworkManager в апстримной конфигурации по умолчанию сейчас использу- ется значение 30 секунд. См. параметр --timeout программы nm-online в файле настроек службы
/usr/lib/systemd/system/NetworkManager-wait-online.service. У systemd-networkd время ожидания ограничивается тайм-аутом systemd для запуска служб, по умолчанию 90 секунд.
136
Прим. перев.: У внимательного читателя может возникнуть вопрос: как же определяется мо- мент активации network-online.target, если юниты, отвечающие за ожидание сети, отключены? На самом деле все довольно просто: при установке NetworkManager/systemd-networkd соответствующие
*-wait-online-юниты прописываются в зависимости к network-online.target при помощи симлинков в /etc/systemd/system/network-online.target.wants. В результате, когда какая-нибудь служба укажет зависимость от network-online.target, будет автоматически активирована и соответствующая служба
*-wait-online. Если таких служб нет, то и активации не произойдет. Однако, если вы принудитель- но включите службу *-wait-online при помощи приведенных выше команд, она будет прописана в зависимости уже к multi-user.target, а значит, будет активироваться при каждой загрузке.
137
Прим. перев.: Собственно, этот путь и является единственно разумным в большинстве случаев.
Привязка network.target к network-online.target, описанная выше, фактически, является пережит- ком проблем старых версий systemd (212 и ниже), когда, по воле его разработчиков, LSB-сущность
$network транслировалась в network.target.
105

G
Моя служба не может получить приоритет realtime
138
Итак, у вас есть служба, которая требует приоритет реального времени
(realtime). Однако, когда вы пытаетесь запустить ее на системе, работающей под управлением systemd, ваша служба не может получить этот приоритет, хотя обла- дает всеми необходимыми для этого привилегиями. Вы хотите понять, почему так происходит, и как это можно исправить.
В чем же дело?
По умолчанию, systemd помещает каждую системную службу в свою контрольную группу в иерархии контроллера cpu. Такое поведение дает очень полезный эффект:
службы с множеством рабочих потоков (например, Apache с сотнями CGI-процессов),
получают примерно такую же долю процессорного времени, как и службы с небольшим количеством рабочих потоков (например, MySQL). Проще говоря, процессорное время распределяется уже не между процессами, а между службами.
К сожалению, в настоящее время реализация cpu-контроллера в Linux имеет один существенный недостаток: она требует явного задания realtime-бюджета времени (RT
budget) для своих контрольных групп. Если же бюджет группы не задан, то ее процес- сы не смогут получить приоритет реального времени (соответствующая операция будет завершаться с ошибкой EPERM — «недостаточно полномочий»). systemd не может при- сваивать такой бюджет каждой группе, просто потому, что не знает, как его правильно делить между ними. Бюджет выдается в абсолютных единицах времени, и их общее количество ограничено. Мы не можем предложить механизм распределения бюджета,
который бы подходил по умолчанию для большинства случаев. Поэтому, в конфигура- ции по умолчанию, приоритет реального времени недоступен для системных служб.
Как это исправить?
Обойти это ограничение несложно. Существует несколько различных путей:
∙ Можно просто отключить использование cpu-контроллера по умолчанию для си- стемных служб. Для этого, задайте в файле /etc/systemd/system.conf параметр
DefaultControllers= равным пустой строке, после чего перезагрузите систему.
(Либо вы можете отключить контроллер cpu на этапе сборки ядра. systemd не пы- тается использовать контроллеры, которые не поддерживаются ядром.)
∙ Также вы можете отключить группировку по cpu только для конкретных служб.
Для этого отредактируйте конфигурацию службы, добавив параметр
ControlGroup=cpu:/
в секцию [Service]. В результате, процессы данной службы будут помещены не в собственную контрольную группу (как это делалось по умолчанию), а в корневую контрольную группу иерархии cpu. Процессы из корневой группы располагают полным realtime-бюджетом.
∙ И наконец, вы можете явно выделить своей службе некоторый бюджет. Для этого добавьте в секцию [Service] строку наподобие
ControlGroupAttribute=cpu.rt_runtime_us 500000
Подробнее о правильном распределении бюджета читайте в документации к ядру
138
Прим. перев.: Перевод статьи «
My Service Can’t Get Realtime!
» с официального сайта проекта, по состоянию на 2013-05-18 08:20:36 (коммит 2f77b).
106

Последние две опции неприменимы к SysV-службам. Тем не менее, вы можете подго- товить для таких служб соответствующие service-файлы, которые, помимо упомянутых выше параметров, содержат вызов соответствующего init-скрипта с аргументом start в ExecStart=, и с аргументом stop — в ExecStop=. (Также имеет смысл задать для них параметры RemainAfterExit=1 и Type=forking.)
Отметим, что все вышесказанное касается только системных служб, и не затрагива- ет пользовательские сеансы. По умолчанию, программы пользователя размещаются в корневой группе контроллера cpu, и поэтому вышеописанные ограничения их не каса- ются.
Мы надеемся, что в будущем ядро будет исправлено таким образом, чтобы не требо- вать явного задания realtime-бюджета для получения приоритета реального времени (а при получении такого приоритета, бюджет процесса должен автоматически выделяться из бюджета ближайшей родительской группы). В идеале, мы хотели бы распростра- нить практику выделения cpu-групп не только на системные службы, но и на пользо- вательские сеансы, чтобы уравнять пользователей в правах на процессорное время, вне зависимости от того, сколько процессов запускает каждый конкретный пользователь.
107

Document Outline

  • Предисловие автора
  • Контроль процесса загрузки
  • О службах и процессах
  • Преобразование SysV init-скрипта в systemd service-файл
  • Убить демона
  • Три уровня выключения
  • Смена корня
  • Поиск виновных
  • Новые конфигурационные файлы
  • О судьбе /etc/sysconfig и /etc/default
  • Экземпляры служб
  • Службы с активацией в стиле inetd
  • К вопросу о безопасности
    • Изолирование служб от сети
    • Предоставление службам независимых каталогов /tmp
    • Ограничение доступа служб к отдельным каталогам
    • Принудительное отключение полномочий (capabilities) для служб
    • Запрет форка, ограничение на создание файлов
    • Контроль доступа служб к файлам устройств
    • Прочие настройки
  • Отчет о состоянии службы и ее журнал
  • Самодокументированный процесс загрузки
  • Сторожевые таймеры
  • Запуск getty на последовательных (и не только) консолях
    • Виртуальные консоли
    • Последовательные консоли
  • Работа с Journal
    • Сохранение логов на диск
    • Основы
    • Контроль доступа
    • Отслеживание логов в реальном времени
    • Простейшие методы выборки записей
    • Продвинутые методы выборки
    • И немного магии
  • Управление ресурсами с помощью cgroups
    • Процессор
    • Отслеживание использования ресурсов
    • Память
    • Ввод-вывод
    • Прочие параметры
  • Проверка на виртуальность
    • Условия на запуск юнитов
    • В скриптах
    • В программах
  • Сокет-активация служб и контейнеров
    • Сокет-активация сетевых служб
    • Сокет-активация контейнеров
  • Интеграция с контейнерами
  • FAQ (часто задаваемые вопросы)
  • Диагностика неполадок
    • Диагностика проблем с загрузкой
      • Если у вас нет доступа к оболочке
      • Если у вас есть доступ к оболочке
    • Диагностика проблем с выключением системы
      • Система очень долго выключается
      • Система не может выключиться самостоятельно
    • Просмотр состояния службы и ее журнала
    • Подготовка сообщений об ошибках
      • Что нужно включить в сообщение об ошибке
  • Совместимость с SysV
  • Предсказуемые имена сетевых интерфейсов
    • Зачем?
    • Что именно было изменено в версии 197?
    • Еще раз, что здесь хорошего?
    • Мне не нравится ваша схема. Как ее отключить?
    • Как именно работает новая схема?
  • Специальные файловые системы
  • Запуск служб после появления сети
    • Как это реализовано в systemd
    • Короче, как заставить network.target работать?
    • А что делать нам, разработчикам?
  • Моя служба не может получить приоритет realtime


Поделитесь с Вашими друзьями:
1   ...   4   5   6   7   8   9   10   11   12


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал