systemd, init - системный менеджер и менеджер сервисов
СИНТАКСИС
/usr/lib/systemd/systemd [ОПЦИИ...]
init [ОПЦИИ...]
ОПИСАНИЕ
systemd — это системный менеджер и менеджер сервисов для операционных систем Linux. При запуске в качестве первого процесса при загрузке (как PID 1), он действует как системный init, который запускает и поддерживает пользовательские сервисы. Отдельные экземпляры запускаются для вошедших в систему пользователей для запуска их сервисов.
systemd обычно не вызывается напрямую пользователем, а устанавливается как символическая ссылка /sbin/init и запускается во время начальной загрузки. Экземпляры менеджера пользователей запускаются автоматически через сервис [email protected](5).
При запуске как системный экземпляр, systemd интерпретирует файл конфигурации system.conf и файлы в каталогах system.conf.d; при запуске как экземпляр пользователя, systemd интерпретирует файл конфигурации user.conf и файлы в каталогах user.conf.d. См. systemd-system.conf(5) для получения дополнительной информации.
systemd содержит собственные реализации различных задач, которые необходимо выполнять в рамках процесса загрузки. Например, он устанавливает имя хоста или настраивает сетевое устройство loopback.
Он также настраивает и монтирует различные файловые системы API, такие как /sys/, /proc/ и /dev/.
systemd также будет сбрасывать системное время во время начальной загрузки, если, по-видимому, оно установлено неправильно. См. раздел «Эпоха системного времени» ниже.
Обратите внимание, что не все, а лишь некоторые интерфейсы, предоставляемые systemd, охвачены обещанием о переносимости и стабильности интерфейса [1].
D-Bus API systemd описан в org.freedesktop.systemd1(5) и org.freedesktop.LogControl1(5).
Системы, которые вызывают systemd в контейнерной или initrd-среде, должны реализовывать спецификации интерфейса контейнера [2] или интерфейса initrd [3], соответственно.
ЕДИНИЦЫ
systemd предоставляет систему зависимостей между различными сущностями, называемыми «единицами» 11 различных типов. Единицы инкапсулируют различные объекты, которые имеют отношение к загрузке системы и обслуживанию. Большинство единиц настроены в файлах конфигурации единиц, синтаксис и базовый набор опций которых описаны в systemd.unit(5), однако некоторые создаются автоматически из других файлов конфигурации, динамически из состояния системы или программно во время выполнения. Единицы могут находиться в различных состояниях, описанных в следующей таблице. Обратите внимание, что различные типы единиц могут иметь ряд дополнительных подсостояний, которые отображаются на обобщенные состояния единиц, описанные здесь.
Таблица 1. Состояния ACTIVE единиц
┌───────────────────────────┬──────────────────────────────────────┐
│ Состояние │ Описание │
├───────────────────────────┼──────────────────────────────────────┤
│ active │ Запущена, связана, подключена, ..., │
│ │ в зависимости от типа единицы. │
├───────────────────────────┼──────────────────────────────────────┤
│ inactive │ Остановилась, не связана, отсоединена, │
│ │ ..., в зависимости от типа единицы. │
├───────────────────────────┼──────────────────────────────────────┤
│ failed │ Подобно inactive, но единица │
│ │ потерпела неудачу каким-либо образом │
│ │ (процесс вернул код ошибки при выходе, │
│ │ завершился аварийно, операция │
│ │ превысила время ожидания или после │
│ │ слишком большого количества перезапусков). │
├───────────────────────────┼──────────────────────────────────────┤
│ activating │ Переход из inactive в active. │
├───────────────────────────┼──────────────────────────────────────┤
│ deactivating │ Переход из active в inactive. │
├───────────────────────────┼──────────────────────────────────────┤
│ maintenance │ Единица неактивна, и выполняется │
│ │ операция обслуживания. │
├───────────────────────────┼──────────────────────────────────────┤
│ reloading │ Единица активна, и она перезагружает │
│ │ свою конфигурацию. │
├───────────────────────────┼──────────────────────────────────────┤
│ refreshing │ Единица активна, и в ее пространстве │
│ │ имен активируется новый экземпляр. │
└───────────────────────────┴──────────────────────────────────────┘
Доступны следующие типы юнитов:
Юниты-сервисы, которые запускают и управляют демонами и процессами, из которых они состоят.
Подробности см. в systemd.service(5).
Юниты-сокеты, которые инкапсулируют локальные IPC или сетевые сокеты в системе, что полезно для активации на основе сокетов. Подробности о юнитах-сокетах см. в systemd.socket(5), а об активации на основе сокетов и других формах активации — в daemon(7).
Целевые юниты полезны для группировки юнитов или для обеспечения известных точек синхронизации во время
загрузки, см. systemd.target(5).
Юниты устройств предоставляют доступ к устройствам ядра в systemd и могут использоваться для реализации
активации на основе устройств. Подробности см. в systemd.device(5).
Юниты монтирования управляют точками монтирования в файловой системе, подробности см. в
systemd.mount(5).
Юниты автоматического монтирования предоставляют возможности автоматического монтирования, обеспечивая
монтирование файловых систем по запросу, а также параллельную загрузку. См. systemd.automount(5).
Юниты таймеров полезны для запуска активации других юнитов на основе таймеров. Подробности можно
найти в systemd.timer(5).
Юниты подкачки очень похожи на юниты монтирования и инкапсулируют разделы памяти подкачки или файлы
операционной системы. Они описаны в systemd.swap(5).
Юниты путей могут использоваться для активации других служб при изменении или изменении объектов
файловой системы. См. systemd.path(5).
Юниты срезов могут использоваться для группировки юнитов, которые управляют системными процессами (такими
как юниты служб и юниты областей) в иерархическом дереве для целей управления ресурсами. См.
systemd.slice(5).
Юниты областей похожи на юниты служб, но управляют внешними процессами вместо того, чтобы запускать их.
См. systemd.scope(5).
Юниты называются по именам своих файлов конфигурации. Некоторые юниты имеют специальную семантику. Подробный список доступен в systemd.special(7).
systemd поддерживает различные типы зависимостей, включая положительные и отрицательные зависимости
(т. е. Requires= и Conflicts=), а также зависимости, определяющие порядок (After= и Before=).
Примечание: зависимости, определяющие порядок, и зависимости, определяющие требования, являются
ортогональными. Если между двумя юнитами существует только зависимость, определяющая требования (например,
foo.service требует bar.service), но нет зависимости, определяющей порядок (например,
foo.service после bar.service), и оба запрошены к запуску, они будут запущены параллельно. Обычно
между двумя юнитами размещаются как зависимости, определяющие требования, так и зависимости, определяющие
порядок. Также следует отметить, что большинство зависимостей создаются и поддерживаются systemd. В
большинстве случаев не должно быть необходимости объявлять дополнительные зависимости вручную, однако это
возможно.
Приложения и юниты (через зависимости) могут запрашивать изменения состояния юнитов. В systemd эти запросы инкапсулируются как «задачи» и хранятся в очереди задач. Задачи могут выполняться успешно или сбоить, их выполнение упорядочивается на основе зависимостей, определяющих порядок, юнитов, для которых они были запланированы.
При загрузке systemd активирует целевой юнит default.target, задача которого состоит в активации служб, запускаемых при загрузке, и других юнитов, запускаемых при загрузке, путем их включения через зависимости. Обычно имя юнита является просто псевдонимом (символической ссылкой) для graphical.target (для полноценной загрузки в графический интерфейс) или multi-user.target (для ограниченной загрузки только в консоль для использования в средах встраиваемых систем или серверов, или аналогичных; подмножество graphical.target). Однако администратор может настроить его как псевдоним для любого другого целевого юнита. Подробности об этих целевых юнитах см. в systemd.special(7).
При первой загрузке systemd включает или отключает юниты в соответствии с предопределенной политикой. См. systemd.preset(5) и раздел «Семантика первой загрузки» в machine-id(5).
systemd хранит в памяти только минимальный набор юнитов. В частности, в памяти хранятся только те юниты, для которых выполняется хотя бы одно из следующих условий:
Он находится в активном, активирующемся, деактивирующемся или неисправном состоянии (то есть в любом состоянии юнита, кроме «неактивного»).
Для него в очереди есть задание.
Он является зависимостью как минимум одного другого юнита, загруженного в память.
У него все еще выделен какой-либо ресурс (например, юнит службы, который находится в неактивном состоянии, но для которого все еще существует процесс, который игнорировал запрос на завершение).
Он программно закреплен в памяти с помощью вызова D-Bus.
systemd автоматически и неявно загружает юниты с диска — если они еще не загружены — сразу после того, как выполняются какие-либо операции с ними. Таким образом, во многих отношениях факт загрузки юнита или его отсутствия не виден клиентам. Используйте `systemctl list-units --all`, чтобы получить полный список всех в настоящее время загруженных юнитов. Любой юнит, для которого не выполняется ни одно из вышеперечисленных условий, оперативно выгружается. Обратите внимание, что при выгрузке юнита из памяти его данные учета также очищаются. Однако эти данные обычно не теряются, поскольку в журнале создается запись, объявляющая об использованных ресурсах, каждый раз, когда юнит завершает работу.
Процессы, создаваемые systemd, помещаются в отдельные группы управления Linux, названные в честь юнита, к которому они принадлежат, в частной иерархии systemd. (См. Control Groups v2[4] для получения дополнительной информации о группах управления или, сокращенно, «cgroups»). Systemd использует это для эффективного отслеживания процессов. Информация о группах управления хранится в ядре и доступна через иерархию файловой системы (под /sys/fs/cgroup/) или в таких инструментах, как systemd-cgls(1) или ps(1) (особенно полезна команда ps xawf -eo pid,user,cgroup,args для перечисления всех процессов и юнитов systemd, к которым они принадлежат).
systemd совместим с различными установленными функциями Unix, такими как /etc/fstab или база данных utmp.
systemd имеет минимальную систему транзакций: если запрошено запуск или остановка юнита, он добавляет его и все его зависимости во временную транзакцию. Затем он проверяет, является ли транзакция согласованной (то есть, не содержит ли порядок всех юнитов циклов). Если нет, systemd попытается исправить это и удалит из транзакции несущественные задания, которые могут устранить цикл. Кроме того, systemd пытается подавить в транзакции несущественные задания, которые остановят работающий сервис. Наконец, проверяется, не противоречат ли задания транзакции заданиям, которые уже были поставлены в очередь, и, возможно, транзакция отменяется. Если все получилось и транзакция согласована и минимизирована по воздействию, она объединяется со всеми остальными ожидающими заданиями и добавляется в очередь выполнения. По сути, это означает, что прежде чем выполнить запрошенную операцию, systemd проверяет, имеет ли это смысл, исправляет ее, если это возможно, и только в случае, если это действительно невозможно, операция завершается с ошибкой.
Обратите внимание, что транзакции генерируются независимо от состояния юнита во время выполнения, поэтому, например, если запрошен запуск юнита, который уже запущен, все равно будет сгенерирована транзакция и активированы любые неактивные зависимости (и произойдет распространение других заданий в соответствии с определенными взаимосвязями). Это связано с тем, что поставленное в очередь задание сравнивается с состоянием целевого юнита в момент выполнения и помечается как успешное и завершенное, когда оба условия выполняются. Однако, это задание также включает в себя другие зависимости из-за определенных взаимосвязей, и, следовательно, в нашем примере, задания на запуск любых неактивных юнитов также будут поставлены в очередь.
Юниты могут генерироваться динамически во время загрузки и перезагрузки системного менеджера, например, на основе других файлов конфигурации или параметров, передаваемых в командной строке ядра. Подробности см. в systemd.generator(7).
ДИРЕКТОРИИ
Системные директории юнитов Системный менеджер systemd считывает конфигурацию юнитов из различных директорий. Пакеты, которые хотят устанавливать файлы юнитов, должны размещать их в директории, возвращаемой командой pkg-config systemd --variable=systemdsystemunitdir. Другие проверяемые директории: /usr/local/lib/systemd/system и /usr/lib/systemd/system. Конфигурация пользователя всегда имеет приоритет. Команда pkg-config systemd --variable=systemdsystemconfdir возвращает путь к директории системной конфигурации. Пакеты должны изменять содержимое этих директорий только с помощью команд enable и disable инструмента systemctl(1). Полный список директорий приведен в systemd.unit(5).
Директории юнитов пользователя Применяются аналогичные правила для директорий юнитов пользователя. Однако здесь следует спецификация XDG Base Directory[5] для поиска юнитов. Приложения должны размещать свои файлы юнитов в директории, возвращаемой командой pkg-config systemd --variable=systemduserunitdir. Глобальная конфигурация выполняется в директории, указанной командой pkg-config systemd --variable=systemduserconfdir. Команды enable и disable инструмента systemctl(1) могут обрабатывать как глобальное (т. е. для всех пользователей), так и частное (для одного пользователя) включение/отключение юнитов. Полный список директорий приведен в systemd.unit(5).
СИГНАЛЫ
Служба прослушивает различные сигналы UNIX, которые можно использовать для запроса различных действий асинхронно. Обработка сигналов включается на очень ранней стадии загрузки, до запуска каких-либо других процессов. Однако управляющий контейнер или аналогичный процесс, который собирается запрашивать эти операции с помощью этого механизма, должен учитывать, что эта функциональность недоступна в самой начальной фазе инициализации. Сообщение уведомления sd_notify(), содержащее поле X_SYSTEMD_SIGNALS_LEVEL=2, отправляется после включения обработчиков сигналов, см. ниже. Это можно использовать для правильного планирования отправки этих сигналов.
SIGTERM
При получении этого сигнала системный менеджер systemd сериализует свое состояние, перезапускает себя и десериализует сохраненное состояние. Это в основном эквивалентно команде systemctl daemon-reexec.
В случае системных менеджеров systemd, при получении этого сигнала будет запущена unit exit.target. Это
в основном эквивалентно команде systemctl --user start exit.target --job-mode=replace-irreversibly.
SIGINT
При получении этого сигнала системный менеджер systemd запустит unit ctrl-alt-del.target. Это в основном эквивалентно команде systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly. Если этот сигнал получен более 7 раз за 2 секунды, будет выполнена немедленная перезагрузка. Обратите внимание, что нажатие Ctrl+Alt+Del на консоли вызовет этот сигнал. Следовательно, если перезагрузка зависла, нажатие Ctrl+Alt+Del более 7 раз в течение 2 секунд — относительно безопасный способ вызвать немедленную перезагрузку.
Системные менеджеры systemd обрабатывают этот сигнал так же, как и SIGTERM.
SIGWINCH
При получении этого сигнала системный менеджер systemd запустит unit kbrequest.target. Это в основном эквивалентно команде systemctl start kbrequest.target.
Этот сигнал игнорируется системными менеджерами systemd.
SIGPWR
При получении этого сигнала менеджер systemd запустит unit sigpwr.target. Это в основном эквивалентно команде systemctl start sigpwr.target.
SIGUSR1
При получении этого сигнала менеджер systemd попытается повторно подключиться к шине D-Bus.
SIGUSR2
При получении этого сигнала менеджер systemd выведет в удобочитаемой форме полное состояние. Данные, выведенные в лог, аналогичны данным, выводимым командой systemd-analyze dump.
SIGHUP
Перезагружает полную конфигурацию демона. Это в основном эквивалентно команде systemctl daemon-reload.
SIGRTMIN+0
Переходит в режим по умолчанию, запускает unit default.target. Это в основном эквивалентно команде systemctl isolate default.target.
SIGRTMIN+1
Переходит в режим восстановления, запускает unit rescue.target. Это в основном эквивалентно команде systemctl isolate rescue.target.
SIGRTMIN+2
Переходит в аварийный режим, запускает unit emergency.service. Это в основном эквивалентно команде systemctl isolate emergency.service.
SIGRTMIN+3
Останавливает машину, запускает unit halt.target. Это в основном эквивалентно команде systemctl start halt.target --job-mode=replace-irreversibly.
SIGRTMIN+4
Выключает машину, запускает unit poweroff.target. Это в основном эквивалентно команде systemctl start poweroff.target --job-mode=replace-irreversibly.
SIGRTMIN+5
Перезагружает машину, запускает unit reboot.target. Это в основном эквивалентно команде systemctl start reboot.target --job-mode=replace-irreversibly.
SIGRTMIN+6
Перезагружает машину с помощью kexec, запускает unit kexec.target. Это в основном эквивалентно команде systemctl start kexec.target --job-mode=replace-irreversibly.
SIGRTMIN+7
Перезагружает пользовательское пространство, запускает юнит soft-reboot.target. Это в основном эквивалентно команде systemctl start soft-reboot.target --job-mode=replace-irreversibly.
Добавлено в версии 254.
SIGRTMIN+13
Немедленно останавливает систему.
SIGRTMIN+14
Немедленно выключает систему.
SIGRTMIN+15
Немедленно перезагружает систему.
SIGRTMIN+16
Немедленно перезагружает систему с использованием kexec.
SIGRTMIN+17
Немедленно перезагружает пользовательское пространство.
Добавлено в версии 254.
SIGRTMIN+20
Включает отображение сообщений о состоянии в консоли, как это контролируется через systemd.show_status=1 в командной строке ядра.
Вместо SIGRTMIN+20 рекомендуется использовать SetShowStatus(), чтобы избежать гонок. См. org.freedesktop.systemd1(5).
SIGRTMIN+21
Отключает отображение сообщений о состоянии в консоли, как это контролируется через systemd.show_status=0 в командной строке ядра.
Вместо SIGRTMIN+21 рекомендуется использовать SetShowStatus(), чтобы избежать гонок. См. org.freedesktop.systemd1(5).
SIGRTMIN+22
Устанавливает уровень ведения журнала менеджера служб в значение «debug», как это эквивалентно systemd.log_level=debug в командной строке ядра.
SIGRTMIN+23
Восстанавливает уровень ведения журнала до его настроенного значения. Настроенное значение определяется в следующем порядке приоритета: значение, указанное с помощью systemd.log-level= в командной строке ядра, или значение, указанное с помощью LogLevel= в файле конфигурации, или значение по умолчанию «info».
Добавлено в версии 239.
SIGRTMIN+24
Немедленно завершает работу менеджера (доступно только для экземпляров --user).
Добавлено в версии 195.
SIGRTMIN+25
При получении этого сигнала менеджер systemd перезапустит себя. Это в основном эквивалентно systemctl daemon-reexec, за исключением того, что это будет сделано асинхронно.
Системный менеджер systemd обрабатывает этот сигнал так же, как и SIGTERM.
Добавлено в версии 250.
SIGRTMIN+26
Восстанавливает целевой объект ведения журнала до его настроенного значения. Настроенное значение определяется в следующем порядке приоритета: значение, указанное с помощью systemd.log-target= в командной строке ядра, или значение, указанное с помощью LogTarget= в файле конфигурации, или значение по умолчанию.
Добавлено в версии 239.
SIGRTMIN+27, SIGRTMIN+28
Устанавливает целевой объект ведения журнала в значение «console» при SIGRTMIN+27 (или «kmsg» при SIGRTMIN+28), как это эквивалентно systemd.log_target=console (или systemd.log_target=kmsg при SIGRTMIN+28) в командной строке ядра.
Добавлено в версии 239.
СРЕДА
Блок среды для системного менеджера изначально устанавливается ядром. (В частности, назначения вида «key=value» в командной строке ядра преобразуются в переменные среды для PID 1. Для пользовательского менеджера системный менеджер устанавливает среду, как описано в разделе «Переменные среды в порожденных процессах» в systemd.exec(5). Настройка DefaultEnvironment= в системном менеджере применяется ко всем службам, включая [email protected]. Дополнительные записи могут быть настроены (как и для любой другой службы) с помощью настроек Environment= и EnvironmentFile= для [email protected] (см. systemd.exec(5). Кроме того, дополнительные переменные среды могут быть установлены с помощью настройки ManagerEnvironment= в systemd-system.conf(5) и systemd-user.conf(5).
Некоторые переменные, используемые systemd:
$SYSTEMD_LOG_LEVEL
Максимальный уровень логируемых сообщений (сообщения с более высоким уровнем, т. е. менее важные, будут подавляться). Принимает список значений, разделенных запятыми. Значение может быть одним из следующих (в порядке убывания важности): emerg, alert, crit, err, warning, notice, info, debug или целым числом в диапазоне 0–7. Подробности см. в man syslog(3). Каждое значение может быть опционально дополнено одним из префиксов console, syslog, kmsg или journal, за которым следует двоеточие, чтобы установить максимальный уровень логирования для конкретной цели (например,
SYSTEMD_LOG_LEVEL=debug,console:info указывает на логирование на уровне debug, за исключением логирования в консоль, которое должно быть на уровне info). Обратите внимание, что глобальный максимальный уровень логирования имеет приоритет над любыми уровнями логирования для конкретных целей.
Это можно переопределить с помощью --log-level=.
$SYSTEMD_LOG_COLOR
Логическое значение. Если true, сообщения, записываемые в tty, будут иметь цвет в соответствии с приоритетом.
Это можно переопределить с помощью --log-color=.
$SYSTEMD_LOG_TIME
Логическое значение. Если true, сообщения в консоли будут иметь префикс с отметкой времени.
Добавлено в версии 246.
Это можно переопределить с помощью --log-time=.
$SYSTEMD_LOG_LOCATION
Логическое значение. Если true, сообщения будут иметь префикс с именем файла и номером строки в исходном коде, откуда происходит сообщение.
Добавлено в версии 247.
Это можно переопределить с помощью --log-location=.
$SYSTEMD_LOG_TID
Логическое значение. Если true, сообщения будут иметь префикс с текущим числовым идентификатором потока (TID).
Это можно переопределить с помощью --log-tid=.
$SYSTEMD_LOG_TARGET
Место назначения для сообщений журнала. Одно из следующих: console (логирование в подключенный tty), console-prefixed (логирование в подключенный tty с префиксами, кодирующими уровень журнала и «facility», см. syslog(3)), kmsg (логирование в буфер кольцевого журнала ядра), journal (логирование в журнал), journal-or-kmsg (логирование в журнал, если он доступен, и в kmsg в противном случае), auto (определение подходящей цели журнала автоматически, по умолчанию), null (отключение вывода журнала).
Это можно переопределить с помощью --log-target=.
$SYSTEMD_LOG_RATELIMIT_KMSG
Определяет, следует ли ограничивать частоту сообщений kmsg. Принимает логическое значение. По умолчанию — «true». Если отключено, systemd не будет ограничивать частоту сообщений, записываемых в kmsg.
Добавлено в версии 254.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Системный менеджер systemd использует эти переменные в соответствии со спецификацией XDG Base Directory[5] для поиска своей конфигурации.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Определяет, где systemd ищет файлы юнитов и генераторы.
Эти переменные могут содержать список путей, разделенных двоеточиями (":"). Если список заканчивается пустой записью ("...:"), этот список добавляется в начало обычного набора путей. В противном случае указанный список заменяет обычный набор путей.
$SYSTEMD_PAGER, $PAGER
Программа постраничного просмотра, используемая, когда не указан параметр --no-pager. Если переменная окружения $SYSTEMD_PAGER установлена, используется она; в противном случае используется $PAGER. Если ни $SYSTEMD_PAGER, ни $PAGER не установлены, по очереди перебирается набор известных программ постраничного просмотра, включая [less]({filename}../../less)(1) и more(1), пока одна из них не будет найдена. Если ни одна программа постраничного просмотра не обнаружена, программа постраничного просмотра не вызывается. Установка этих переменных окружения в пустую строку или значение "cat" эквивалентна использованию параметра --no-pager.
Примечание: если $SYSTEMD_PAGERSECURE не установлена, $SYSTEMD_PAGER и $PAGER могут использоваться только для отключения программы постраничного просмотра (с помощью "cat" или ""), в противном случае они игнорируются.
$SYSTEMD_LESS
Переопределяет параметры, передаваемые программе less (по умолчанию "FRSXMK").
Пользователи могут захотеть изменить два параметра в частности:
K
Этот параметр указывает программе постраничного просмотра немедленно завершать работу при нажатии Ctrl+C. Чтобы разрешить программе less обрабатывать Ctrl+C самостоятельно и возвращаться к командной строке программы постраничного просмотра, отключите этот параметр.
Если в значении $SYSTEMD_LESS отсутствует "K", и вызываемая программа постраничного просмотра — less, Ctrl+C будет игнорироваться исполняемым файлом и должна обрабатываться программой постраничного просмотра.
X
Этот параметр указывает программе постраничного просмотра не отправлять строки инициализации и деинициализации termcap в терминал. Он установлен по умолчанию, чтобы вывод команды оставался видимым в терминале даже после завершения работы программы постраничного просмотра. Тем не менее, это не позволяет некоторым функциям программы постраничного просмотра работать, в частности, невозможно прокручивать выходные данные с помощью мыши.
Обратите внимание, что установка обычной переменной окружения $LESS не оказывает никакого влияния на вызовы less, выполняемые инструментами systemd.
См. [less]({filename}../../less)(1) для получения дополнительной информации.
$SYSTEMD_LESSCHARSET
Переопределяет кодировку, передаваемую программе less (по умолчанию "utf-8", если вызывающий терминал определен как совместимый с UTF-8).
Обратите внимание, что установка обычной переменной окружения $LESSCHARSET не оказывает никакого влияния на вызовы less, выполняемые инструментами systemd.
$SYSTEMD_PAGERSECURE
Обычные команды программ постраничного просмотра, такие как [less]({filename}../../less)(1), помимо "постраничного просмотра", т. е. прокрутки выходных данных, поддерживают открытие или запись в другие файлы, а также выполнение произвольных команд оболочки. Когда команды вызываются с повышенными привилегиями, например, с помощью [sudo]({filename}../../sudo)(8) или pkexec(1), программа постраничного просмотра становится границей безопасности. Необходимо убедиться, что в качестве программ постраничного просмотра используются только программы с строго ограниченной функциональностью, и что непреднамеренные интерактивные функции, такие как открытие или создание новых файлов или запуск подпроцессов, не разрешены. "Безопасный режим" для программы постраничного просмотра может быть включен, как описано ниже, если программа постраничного просмотра поддерживает это (большинство программ постраничного просмотра не разработаны с учетом этого). Рекомендуется либо явно включить "безопасный режим", либо полностью отключить программу постраничного просмотра с помощью --no-pager или PAGER=cat, когда непроверенные пользователи могут выполнять команды с повышенными привилегиями.
Эта опция принимает булево значение. При установке в true, включается «защищенный режим» пейджера. В «защищенном режиме» при вызове пейджера будет установлена переменная LESSSECURE=1, которая указывает пейджеру отключить команды, открывающие или создающие новые файлы или запускающие новые подпроцессы. В настоящее время только less(1) известно, что он понимает эту переменную и реализует «защищенный режим».
При установке в false никакие ограничения на пейджер не накладываются. Установка SYSTEMD_PAGERSECURE=0 или отсутствие ее в унаследованной среде может позволить пользователю вызывать произвольные команды.
Если переменная $SYSTEMD_PAGERSECURE не установлена, инструменты systemd пытаются автоматически определить, следует ли включать «защищенный режим» и поддерживает ли его пейджер. «Защищенный режим» включается, если эффективный UID не совпадает с UID владельца сеанса входа в систему, см. geteuid(2) и sd_pid_get_owner_uid(3), или при запуске под sudo(8) или аналогичными инструментами (установлена переменная $SUDO_UID [6]). В этих случаях SYSTEMD_PAGERSECURE=1 будет установлена, и пейджеры, которые не поддерживают «защищенный режим», использоваться не будут. Обратите внимание, что это автоматическое обнаружение охватывает только наиболее распространенные механизмы повышения привилегий и предназначено для удобства. Рекомендуется явно установить $SYSTEMD_PAGERSECURE или отключить пейджер.
Обратите внимание, что если переменные $SYSTEMD_PAGER или $PAGER должны учитываться, кроме отключения пейджера, то $SYSTEMD_PAGERSECURE также должна быть установлена.
$SYSTEMD_COLORS
Принимает булево значение. Если true, systemd и связанные с ним утилиты будут использовать цвета в своем выводе, в противном случае вывод будет монохромным. Кроме того, переменная может принимать одно из следующих специальных значений: "16", "256", чтобы ограничить использование цветов базовыми 16 или 256 цветами ANSI соответственно. Это можно указать, чтобы переопределить автоматическое решение на основе $TERM и того, к чему подключена консоль.
$SYSTEMD_URLIFY
Значение должно быть булевым. Определяет, следует ли генерировать кликабельные ссылки в выводе для терминальных эмуляторов, поддерживающих эту функцию. Это можно указать, чтобы переопределить решение, которое systemd принимает на основе $TERM и других условий.
$LISTEN_PID, $LISTEN_PIDFDID, $LISTEN_FDS, $LISTEN_FDNAMES
Устанавливаются systemd для контролируемых процессов во время активации на основе сокетов. См. sd_listen_fds(3) для получения дополнительной информации.
$NOTIFY_SOCKET
Устанавливается менеджером служб для его служб для уведомлений о состоянии и готовности. Также используется менеджером служб для уведомления вышестоящих контейнерных менеджеров или менеджеров служб о его прогрессе. См. sd_notify(3) и соответствующий раздел ниже для получения дополнительной информации.
Для получения дополнительной информации о переменных среды, используемых systemd и его различными компонентами, см. Известные переменные среды[7].
ПАРАМЕТРЫ ЯДРА
При запуске в качестве системного экземпляра systemd анализирует ряд опций, перечисленных ниже. Их можно указать в качестве аргументов командной строки ядра, которые анализируются из различных источников в зависимости от среды, в которой выполняется systemd. Если он работает внутри контейнера Linux, эти параметры анализируются из аргументов командной строки, передаваемых в systemd, в дополнение ко всем другим параметрам командной строки, перечисленным в разделе «Параметры» выше. Если он работает за пределами контейнеров Linux, эти аргументы анализируются из /proc/cmdline.
Следующие переменные используются:
systemd.unit=, rd.systemd.unit=
Переопределяет юнит, который будет активирован при загрузке. По умолчанию используется default.target. Это может быть использовано для временного запуска в другой юнит при загрузке, например, rescue.target или emergency.service.
См. systemd.special(7) для получения подробной информации об этих юнитах. Опция с префиксом "rd." действует только в initrd, а опция без префикса — только в основной системе.
systemd.dump_core
Принимает булево значение в качестве аргумента или включает опцию, если она указана без аргумента. Если включено, менеджер systemd (PID 1) создает дамп памяти при сбое. В противном случае дамп памяти не создается. По умолчанию включено.
Добавлено в версии 233.
systemd.crash_chvt
Принимает положительное целое число или булево значение в качестве аргумента. Также может быть указано без аргумента, что имеет тот же эффект, что и положительное булево значение. Если указано положительное целое число (в диапазоне 1–63), менеджер системы (PID 1) активирует указанный виртуальный терминал при сбое. По умолчанию отключено, что означает, что такая переадресация не выполняется. Если установлено значение enabled, используется виртуальный терминал, в который выводятся сообщения ядра.
Добавлено в версии 233.
systemd.crash_shell
Принимает булево значение в качестве аргумента или включает опцию, если она указана без аргумента. Если включено, менеджер системы (PID 1) запускает оболочку при сбое. В противном случае оболочка не запускается. По умолчанию отключено, в целях безопасности, поскольку оболочка не защищена аутентификацией по паролю.
Добавлено в версии 233.
systemd.crash_action=
Принимает одно из значений: freeze, reboot или poweroff. По умолчанию freeze. Если установлено значение freeze, система будет бесконечно зависать при сбое менеджера системы (PID 1). Если установлено значение reboot, менеджер системы (PID 1) автоматически перезагрузит машину после 10-секундной задержки. Если установлено значение poweroff, менеджер системы (PID 1) немедленно выключит машину при сбое. Если используется в сочетании с systemd.crash_shell, настроенное действие при сбое выполняется после завершения работы оболочки.
Добавлено в версии 256.
systemd.confirm_spawn
Принимает булево значение в качестве аргумента или путь к виртуальной консоли, на которой должны выводиться сообщения подтверждения. Также может быть указано без аргумента, что имеет тот же эффект, что и положительное булево значение. Если включено, менеджер системы (PID 1) запрашивает подтверждение при запуске процессов с использованием /dev/console. Если указан путь или имя консоли (например, ttyS0), будет использоваться виртуальная консоль, на которую указывает этот путь или которая описывается данным именем.
По умолчанию отключено.
Добавлено в версии 233.
systemd.service_watchdogs=
Принимает булево значение в качестве аргумента. Если отключено, все сторожевые таймеры служб (WatchdogSec=) и действия в случае сбоя (например, OnFailure= или StartLimitAction=) игнорируются диспетчером системы (PID 1); см. systemd.service(5). По умолчанию включено, то есть сторожевые таймеры и действия в случае сбоя обрабатываются нормально. Аппаратный сторожевой таймер не подвержен влиянию этой опции.
Добавлено в версии 237.
systemd.show_status
Принимает булево значение или константы error и auto в качестве аргумента. Также может быть указано без аргумента, что дает тот же эффект, что и положительное булево значение. Если включено, диспетчер systemd (PID 1) отображает краткие сообщения о состоянии служб в консоли во время загрузки. При значении error отображаются только сообщения об ошибках, но загрузка в остальном происходит тихо. auto ведет себя как false, пока не возникает значительная задержка при загрузке. По умолчанию включено, если только quiet не передается в качестве параметра командной строки ядра, в этом случае по умолчанию используется error. Если указано, переопределяет опцию конфигурационного файла диспетчера системы ShowStatus=, см. systemd-system.conf(5).
Добавлено в версии 233.
systemd.status_unit_format=
Принимает значения name, description или combined. Если указано name, диспетчер системы будет использовать имена юнитов в сообщениях о состоянии. Если указано combined, диспетчер системы будет использовать имена юнитов и описания в сообщениях о состоянии. При указании переопределяет опцию конфигурационного файла диспетчера системы StatusUnitFormat=, см. systemd-system.conf(5).
Добавлено в версии 243.
systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=,
systemd.log_time, systemd.log_tid, systemd.log_ratelimit_kmsg
Управляет выводом журнала, аналогично переменным среды $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION, $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_TIME, $SYSTEMD_LOG_TID и $SYSTEMD_LOG_RATELIMIT_KMSG, описанным выше. systemd.log_color, systemd.log_location, systemd.log_time, systemd.log_tid и systemd.log_ratelimit_kmsg могут быть указаны без аргумента, что дает тот же эффект, что и положительное булево значение.
systemd.default_standard_output=, systemd.default_standard_error=
Управляет стандартным выводом и выводом ошибок по умолчанию для служб и сокетов. То есть управляет значением по умолчанию для StandardOutput= и StandardError= (см. systemd.exec(5) для получения подробной информации). Принимает одно из значений: inherit, null, tty, journal, journal+console, kmsg, kmsg+console. Если аргумент опущен, systemd.default-standard-output= по умолчанию принимает значение journal, а systemd.default-standard-error= – значение inherit.
systemd.setenv=
Принимает строковый аргумент в формате VARIABLE=VALUE. Может использоваться для установки переменных среды по умолчанию, которые будут добавлены для дочерних процессов. Может использоваться несколько раз для установки нескольких переменных.
systemd.machine_id=
Принимает 32-символьное шестнадцатеричное значение, которое будет использоваться для установки machine-id. Предназначено в основном для сетевой загрузки, когда требуется, чтобы для каждой загрузки использовался один и тот же machine-id.
Добавлено в версии 229.
systemd.set_credential=, systemd.set_credential_binary=
Задает системный учетный параметр, который затем можно передать системным службам с помощью
параметров ImportCredential= или LoadCredential=, см. systemd.exec(5) для получения подробной информации. Принимает пару
имя и значение учетного параметра, разделенные двоеточием. Параметр systemd.set_credential=
ожидает значение учетного параметра в виде обычного текста, параметр systemd.set_credential_binary=
принимает двоичные данные, закодированные в Base64. Следует отметить, что командная строка ядра обычно доступна для не привилегированных программ в /proc/cmdline. Таким образом, этот механизм не подходит для передачи конфиденциальных данных. Используйте его только для неконфиденциальных данных (например, общедоступных ключей/сертификатов, а не закрытых ключей) или в тестовых/отладочных средах.
Для получения дополнительной информации см. документацию System and Service Credentials[8].
Добавлено в версии 251.
systemd.import_credentials=
Принимает логический аргумент. Если установлено значение false, отключает импорт учетных данных из командной строки ядра, таблицы строк OEM DMI/SMBIOS, подсистемы qemu_fw_cfg или загрузчика EFI.
Добавлено в версии 251.
quiet
Отключает вывод статуса при загрузке, аналогично systemd.show_status=no. Обратите внимание, что эта опция также считывается самим ядром и отключает вывод журнала ядра. Передача этой опции, следовательно, отключает обычный вывод как от системного менеджера, так и от ядра.
Добавлено в версии 186.
debug
Включает вывод отладочной информации. Это эквивалентно systemd.log_level=debug. Обратите внимание, что эта опция также считывается самим ядром и включает вывод отладочной информации ядра. Передача этой опции, следовательно, включает вывод отладочной информации как от системного менеджера, так и от ядра.
Добавлено в версии 205.
emergency, rd.emergency, -b
Загружает систему в аварийном режиме. Это эквивалентно systemd.unit=emergency.target или
rd.systemd.unit=emergency.target, соответственно, и предоставляется для обеспечения совместимости и для удобства ввода.
Добавлено в версии 186.
rescue, rd.rescue, single, s, S, 1
Загружает систему в режиме восстановления. Это эквивалентно systemd.unit=rescue.target или
rd.systemd.unit=rescue.target, соответственно, и предоставляется для обеспечения совместимости и для удобства ввода.
Добавлено в версии 186.
2 3, 4, 5
Загружает систему в указанный устаревший уровень выполнения SysV. 2, 3 и 4 эквивалентны
systemd.unit=multi-user.target; а 5 эквивалентно systemd.unit=graphical.target, и предоставляется для обеспечения совместимости и для удобства ввода.
Добавлено в версии 186.
locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=
Задает системную локаль для использования. Это переопределяет настройки в /etc/locale.conf. Для получения дополнительной информации см. locale.conf(5) и locale(7).
Добавлено в версии 186.
Для получения информации о других параметрах командной строки ядра, которые используются компонентами основной ОС, обратитесь к kernel-command-line(7).
СИСТЕМНЫЕ УЧЕТНЫЕ ДАННЫЕ
Во время инициализации менеджер служб импортирует учетные данные из различных источников в набор учетных данных системы, которые затем могут быть переданы службам и использованы генераторами:
При первой инициализации менеджер служб считывает системные учетные данные из строк SMBIOS Type 11 vendor с форматом io.systemd.credential:name=value и io.systemd.credential.binary:name=value.
Одновременно он импортирует учетные данные из QEMU "fw_cfg". (Следует отметить, что механизм SMBIOS обычно предпочтительнее, поскольку он быстрее и более универсален).
Учетные данные можно передавать через командную строку ядра, используя параметр systemd.set-credential=, см. выше.
Учетные данные могут быть переданы из среды UEFI через systemd-stub(7).
Когда менеджер служб вызывается во время перехода initrd → host, он импортирует все файлы в /run/credentials/@initrd/ в качестве системных учетных данных.
Вызовите systemd-creds(1) следующим образом, чтобы увидеть список учетных данных, переданных в систему:
# systemd-creds --system list
Для получения дополнительной информации обратитесь к документации System and Service Credentials[8].
Менеджер служб, работающий в качестве PID 1, использует следующие системные учетные данные:
vmm.notify_socket
Содержит адрес AF_VSOCK или AF_UNIX, на который отправляется сообщение уведомления READY=1 после завершения загрузки менеджера служб. См. sd_notify(3) и следующий раздел для получения дополнительной информации. Обратите внимание, что в случае, если гипервизор не поддерживает SOCK_DGRAM через AF_VSOCK, будет предпринята попытка использования SOCK_SEQPACKET. Полезная нагрузка учетных данных для AF_VSOCK должна быть строкой в формате "vsock:CID:PORT". "vsock-stream", "vsock-dgram" и "vsock-seqpacket" могут использоваться вместо "vsock", чтобы принудительно использовать соответствующий тип сокета.
Эта функция полезна для менеджеров машин или других процессов на хосте, чтобы получать уведомление через VSOCK о завершении загрузки виртуальной машины.
Добавлено в версии 254.
system.machine_id
Принимает 128-битный шестнадцатеричный идентификатор для инициализации /etc/machine-id, если файл еще не настроен. См. machine-id(5) для получения подробной информации.
Добавлено в версии 254.
Список системных учетных данных, которые используют различные другие компоненты systemd, см. в systemd.systemcredentials(7).
ПРОТОКОЛ ГОТОВНОСТИ
Менеджер служб реализует протокол уведомления о готовности как между менеджером и его службами (то есть по иерархии), так и между менеджером и потенциальным супервизором выше по иерархии (последний может быть менеджером машин или контейнеров или, в случае менеджера служб для одного пользователя, экземпляром системного менеджера служб). Базовый протокол (и предлагаемый API для него) описан в sd_notify(3).
Сокет уведомлений, который менеджер служб (включая PID 1) использует для сообщения о готовности своему собственному супервизору, задается с помощью обычной переменной среды $NOTIFY_SOCKET (см. выше). Поскольку это можно установить напрямую только для менеджеров контейнеров и для экземпляра менеджера служб для одного пользователя, доступен дополнительный механизм для настройки этого, в частности, предназначенный для использования в средах виртуальных машин: системный учетный параметр vmm.notify_socket (см. выше) можно установить на подходящий сокет (обычно AF_VSOCK) через строки SMBIOS Type 11 vendor. Подробности см. выше.
Протокол уведомлений от диспетчера служб, направленный вверх по иерархии к супервизору, поддерживает ряд расширенных полей, позволяющих супервизору узнавать о конкретных свойствах системы и отслеживать ход ее загрузки. В частности, отправляются следующие поля:
Сообщение X_SYSTEMD_HOSTNAME=... будет отправлено после определения начального имени хоста для системы. Обратите внимание, что позже имя хоста может быть изменено программным путем, и (в настоящее время) дополнительные уведомления в этом случае не отправляются.
Добавлено в версии 256.
Сообщение X_SYSTEMD_MACHINE_ID=... будет отправлено после определения идентификатора машины системы. Подробности см. в man machine-id(5).
Добавлено в версии 256.
Сообщение X_SYSTEMD_SIGNALS_LEVEL=... будет отправлено после того, как диспетчер служб установит различные обработчики сигналов UNIX-процессов, описанные выше. Значение поля — беззнаковое целое число в десятичном формате, указывающее поддерживаемый диспетчером служб уровень функций UNIX-процессов. В настоящее время определен только один уровень функций:
X_SYSTEMD_SIGNALS_LEVEL=2 охватывает различные сигналы UNIX-процессов, описанные выше, которые являются надмножеством сигналов, поддерживаемых исторической системой SysV init.
Сигналы, отправленные в PID 1 до отправки этого сообщения, могут быть обработаны некорректно. Компонент, получающий эти сообщения, должен анализировать значение как беззнаковое целое число, указывающее уровень поддержки. Пока определен только указанный выше уровень 2, но в дальнейшем могут быть определены дополнительные уровни с более высокими значениями, которые будут реализовывать надмножество текущего поведения.
Добавлено в версии 256.
Сообщения X_SYSTEMD_UNIT_ACTIVE=... и X_SYSTEMD_UNIT_INACTIVE=... будут отправляться для каждой целевой единицы по мере ее активации или прекращения активности. Это полезно для отслеживания хода загрузки и функциональности. Например, после того как будет сообщено о запуске единицы ssh-access.target, доступ SSH обычно становится доступным, см. systemd.special(7) для получения подробной информации.
Добавлено в версии 256.
Сообщение X_SYSTEMD_SHUTDOWN=... будет отправлено непосредственно перед завершением работы системы. Значение — одна из строк "reboot", "halt", "poweroff", "kexec", указывающая, какой тип завершения работы выполняется.
Добавлено в версии 256.
Сообщение X_SYSTEMD_REBOOT_PARAMETER=... также будет отправлено непосредственно перед завершением работы системы. Его значение — аргумент перезагрузки, заданный с помощью systemctl --reboot-argument=....
Добавлено в версии 256.
Обратите внимание, что эти расширенные поля отправляются в дополнение к обычным уведомлениям "READY=1" и "RELOADING=1".
ОПЦИИ
systemd вызывается напрямую очень редко, поскольку он запускается на ранней стадии и уже работает к тому времени, когда пользователи могут взаимодействовать с ним. Обычно используются такие инструменты, как [systemctl]({filename}../../systemctl)(1), для отправки команд менеджеру. Поскольку systemd обычно не вызывается напрямую, приведенные ниже опции в основном полезны для отладки и специальных целей.
Параметры для интроспекции и отладки
Эти параметры используются для тестирования и интроспекции, и systemd может быть запущен с ними в любое время:
--dump-configuration-items
Вывести список понятных элементов конфигурации юнитов. Эта команда выводит краткий, но полный список элементов конфигурации, понятных в файлах определения юнитов.
--dump-bus-properties
Вывести список доступных свойств шины. Эта команда выводит краткий, но полный список свойств, доступных через D-Bus.
Добавлено в версии 239.
--test
Определить начальную транзакцию запуска (т.е. список заданий, помещенных в очередь при запуске), вывести ее и завершить работу — без фактического выполнения каких-либо из определенных заданий. Этот параметр полезен только для отладки. Обратите внимание, что во время обычного запуска системного менеджера могут быть запущены дополнительные юниты, не отображаемые этой операцией, поскольку оборудование, сокет, шина или другие виды активации могут добавлять дополнительные задания по мере выполнения транзакции. Используйте --system, чтобы запросить начальную транзакцию системного менеджера (это также подразумеваемая настройка по умолчанию), используйте в сочетании с --user, чтобы запросить начальную транзакцию менеджера служб для конкретного пользователя.
--system, --user
При использовании в сочетании с --test определяет, следует ли вычислять начальную транзакцию для системного экземпляра или для экземпляра для конкретного пользователя. Эти параметры не имеют эффекта, если они вызываются без --test, поскольку во время обычных (т.е. не --test) вызовов системный менеджер автоматически определяет, должен ли он работать в системном режиме или в режиме для конкретного пользователя, проверяя, равен ли PID, под которым он запущен, 1 или нет. Обратите внимание, что не поддерживается запуск и обслуживание системы с системным менеджером, работающим в режиме --system, но с PID, отличным от 1.
-h, --help
Вывести краткий текст справки и завершить работу.
--version
Вывести краткую строку версии и завершить работу.
Параметры, дублирующие параметры командной строки ядра
Эти параметры напрямую соответствуют параметрам, перечисленным выше в разделе «Параметры командной строки ядра». Оба формата могут использоваться взаимозаменяемо для системного менеджера, но рекомендуется использовать формы, перечисленные выше в этом контексте, поскольку они правильно именованы. Если параметр указан как в командной строке ядра, так и в виде обычного аргумента командной строки, последний имеет более высокий приоритет.
Когда systemd используется в качестве пользовательского менеджера, командная строка ядра игнорируется, и понимаются только параметры, описанные ниже. Тем не менее, systemd обычно запускается в этом режиме через службу [email protected](5), которая используется всеми пользователями. Может быть более удобно использовать файлы конфигурации для изменения настроек (см. systemd-user.conf(5)) или переменные окружения. См. раздел «Окружение» выше для обсуждения того, как устанавливается блок окружения.
--unit=
Устанавливает единицу, которая будет активирована при запуске по умолчанию. Если не указано, используется default.target. См. systemd.unit= выше.
--dump-core
Включает создание дампа памяти при сбое. Этот параметр не имеет эффекта при запуске в качестве пользовательского экземпляра. То же, что и systemd.dump_core= выше.
--crash-vt=VT
Переключает на указанную виртуальную консоль (VT) при сбое. Этот параметр не имеет эффекта при запуске в качестве пользовательского экземпляра. То же, что и systemd.crash_chvt= выше (но с другим написанием!).
Добавлено в версии 227.
--crash-shell
Запускает оболочку при сбое. Этот параметр не имеет эффекта при запуске в качестве пользовательского экземпляра. См. systemd.crash_shell= выше.
--crash-action=
Указывает, что делать при сбое системного менеджера (PID 1). Этот параметр не имеет эффекта, когда systemd работает в качестве пользовательского экземпляра. См. systemd.crash_action= выше.
Добавлено в версии 256.
--confirm-spawn
Запрашивает подтверждение при запуске процессов. Этот параметр не имеет эффекта при запуске в качестве пользовательского экземпляра. См. systemd.confirm_spawn выше.
--show-status
Отображает краткую информацию о состоянии юнита в консоли во время загрузки и выключения. См. systemd.show_status выше.
Добавлено в версии 244.
--log-color
Выделяет важные сообщения журнала цветом. См. systemd.log_color выше.
Добавлено в версии 244.
--log-level=
Устанавливает уровень ведения журнала. См. systemd.log_level выше.
--log-location
Включает отображение местоположения кода в сообщениях журнала. См. systemd.log_location выше.
Добавлено в версии 244.
--log-target=
Устанавливает цель ведения журнала. См. systemd.log_target выше.
--log-time=
Добавляет метку времени к сообщениям в консоли. См. systemd.log_time выше.
Добавлено в версии 246.
--machine-id=
Переопределяет machine-id, установленный на жестком диске. См. systemd.machine_id= выше.
Добавлено в версии 229.
--service-watchdogs
Глобально включает или отключает все тайм-ауты и аварийные действия для служб. См. systemd.service_watchdogs выше.
Добавлено в версии 237.
--default-standard-output=, --default-standard-error=
Устанавливает стандартный вывод или вывод ошибок по умолчанию для всех служб и сокетов соответственно. См. systemd.default_standard_output= и systemd.default_standard_error= выше.
ЭПОХА СИСТЕМНЫХ ЧАСОВ
При запуске или перезапуске systemd может установить системные часы на "эпоху". Этот механизм используется для обеспечения того, чтобы системные часы оставались разумно инициализированными и примерно монотонными между перезагрузками, в случае, если отсутствует батарейка для локальных RTC или она не работает должным образом.
Эпоха — это самая ранняя дата, после которой предполагается, что время системных часов установлено правильно. При инициализации локальные часы переносятся на эпоху, если они были установлены на более раннее значение. В качестве особого случая, если локальные часы значительно опережают (по умолчанию 15 лет, но это можно настроить во время сборки), предполагается, что аппаратные часы неисправны, и системные часы возвращаются к эпохе.
Эпоха устанавливается равной наибольшему из следующих значений: время сборки systemd, время изменения ("mtime") файла /usr/lib/clock-epoch и время изменения файла /var/lib/systemd/timesync/clock.
ФАЙЛЫ
/run/systemd/notify
Сокет для уведомлений о статусе демона. Это AF_UNIX-сокет, используемый для реализации логики уведомлений демона, реализованной функцией sd_notify(3).
/run/systemd/private
Используется как внутренний канал связи между systemctl(1) и процессом systemd. Это AF_UNIX-сокет. Этот интерфейс является внутренним для systemd и не должен использоваться во внешних проектах.
/usr/lib/clock-epoch
Время модификации ("mtime") этого файла используется для эпохи времени, см. предыдущий раздел.
Добавлено в версии 247.
/var/lib/systemd/timesync/clock
Время модификации ("mtime") этого файла обновляется службой systemd-timesyncd.service(8). Если он присутствует, время модификации файла используется для эпохи, см. предыдущий раздел.
Добавлено в версии 257.
ИСТОРИЯ
systemd 252
Аргументы командной строки ядра systemd.unified_cgroup_hierarchy и systemd.legacy_systemd_cgroup_controller устарели. Пожалуйста, перейдите на единую иерархию cgroup.
СМ. ТАКЖЕ
Домашняя страница systemd[9], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7), org.freedesktop.systemd1(5)
Для получения дополнительной информации о концепциях и идеях, лежащих в основе systemd, обратитесь к оригинальному документу[10].
ЗАМЕТКИ
Обещание о переносимости и стабильности интерфейса
https://systemd.io/PORTABILITY_AND_STABILITY/
Интерфейс контейнера
https://systemd.io/CONTAINER_INTERFACE
Интерфейс initrd
https://systemd.io/INITRD_INTERFACE/
Группы управления v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
Спецификация базового каталога XDG
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Рекомендуется, чтобы другие инструменты устанавливали и проверяли $SUDO_UID по мере необходимости, рассматривая это как общий интерфейс.
Известные переменные среды
https://systemd.io/ENVIRONMENT
Учетные данные системы и службы
https://systemd.io/CREDENTIALS
Домашняя страница systemd
https://systemd.io/
Оригинальный проект
https://0pointer.de/blog/projects/systemd.html