Партнёры:
Хостинг:
NAME
systemd, init - systemd System and Service Manager
SYNOPSIS
systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}
DESCRIPTION
systemd представляет собой системный и сервисный менеджер для операционной
системы Linux. При выполнении в качестве первого процесса загрузки (PID-1),
он выступает в качестве системы инициализации , которая запускает и
поддерживает сервисы пользовательского пространства.
Для совместимости с SysV, если systemd вызывается как init и PID которого
не 1, он будет выполнять telinit и передавать все аргументы командной
строки без изменений. Это означает, что init и telinit в основном
эквивалентны, если вызывается из нормального сеанса. Смотрите telinit(8)
для получения дополнительной информации.
При запуске, в качестве системной инстанции, systemd интерпретирует файл
конфигурации system.conf, в противном случае user.conf. Смотрите
systemd.conf (5) для получения дополнительной информации.
OPTIONS
Понимает следующие опции:
-h, --help
Печать короткого текста помощи и выход.
--test
Определяет последовательность запуска, выводит ее и выходит. Эта
опция полезна только для отладки.
--dump-configuration-items
Вывод используемых элементов конфигурации модулей. Выводится
краткий, но полный список элементов конфигурации, которые
используются в настроечных файлах модулей.
--introspect=
Извлечение данных самоанализа D-Bus интерфейса. В основном, это
полезно во время инсталляции для получения данных, пригодных для
репозитория D-Bus интерфейсов. При желании имя интерфейса для данных
самоанализа может быть указано. Если оно опущено, данные самоанализа
выводятся для всех интерфейсов.
--unit=
Установить по умолчанию модуль для активации при запуске. Если не
указано, то по умолчанию - default.target.
--system, --user
Говорит systemd запустить системную инстанцию (соответственно,
пользовательскую инстанцию), даже если ID процесса не равен 1
(соответственно равен 1), т.е. systemd не выполняется (соответственно
выполняется) в качестве процесса инициализации. Обычно нет
необходимости задавать эти опции,так как systemd автоматически
определяет режим своего запуска. Эти варианты, следовательно, мало
полезны, кроме случае отладки. Обратите внимание, что не
обеспечивается загрузка и поддержка полной системы с systemd
запущенной в режиме --system при PID не равном 1. На практике,
задание опции --system явно имеет смысл только в сочетании с опцией
--test.
--dump-core
Дамп ядра при крахе. Эта опция не имеет эффекта, в случае запуска
в пользовательской инстанции.
--crash-shell
Запускать shell при крахе. Эта опция не имеет эффекта, в случае
запуска в пользовательской инстанции.
--confirm-spawn
Запрашивать подтверждение при размножении процессов.Эта опция не имеет
эффекта, в случае запуска в пользовательской инстанции.
--show-status=
Показывать сжатую статусную информацию о сервисах при загрузке.
Эта опция не имеет эффекта при выполнении в пользовательской инстанции.
Принимает булевский аргумент, который может быть пропущен, что
интерпретируется как true.
--sysv-console=
Определяет будет ли вывод SysV скрипта инициализации направлен на
консоль. Эта опции не будет иметь эффекта при выполнении в
пользовательской инстанции. Принимает булевский аргумент, который
может быть пропущен, что интерпретируется как true.
--log-target=
Задает приемник для логов. Аргумент должен быть одним из следующих
console, syslog, kmsg, syslog-or-kmsg, null.
--log-level=
Задает уровень журналирования. В качестве аргумента принимается
числовой уровень журналирования или хорошо известные syslog(3)
символические имена (в нижнем регистре):emerg, alert, crit, err,
warning, notice, info, debug.
--log-color=
Выделение важных журнальных сообщений. Аргумент - булевое
значение. Если аргумент пропущен, то по умолчанию считается true.
--log-location=
Включать расположения в коде в журнальные сообщения. Это наиболее
значимо для целей отладки. Аргумент - булевое значение. Если аргумент
пропущен, то по умолчанию считается true.
--default-standard-output=, --default-standard-error=
Задает вывод оп умолчанию или соответственно вывод ошибок для
всех сервисов и сокетов, тоесть управляет значение по умолчанию
для StandardOutput= и соответственно для StandardExecute= (см.
systemd.exec(5) для деталей). Воспринимает одно из следующих
значений inherit, null, tty, syslog, syslog+console, kmsg,
kmsg+console. Если аргумент пропущен, то по умолчанию считается
inherit.
CONCEPTS
systemd предусматривает систему зависимостей между "разными" элементами
называемыми "units"(юнит). Юниты инкапсулируют различные объекты, которые
важны для загрузки системы и поддержки. Большинство юнитов настроены
в файлах конфигурации юнитов, чей синтаксис и базовый набор опций
описан в systemd.unit (5), однако некоторые из них создаются
автоматически из других конфигураций или динамически из системных
структур. Юниты могут быть "active"( что подразумевает started, bound,
plugged in, ... в зависимости от типа устройства, см. ниже), или
"inactive" ( что подразумевает stopped, unbound, unplugged, ...), а
также находиться в процессе активировании или деактивации, то есть
между двумя состояниями (эти состояния называются 'activating',
'deactivating'). Также возможно специальное состояние "failed", которое
очень похоже на "inactive" и возникает, когда сервис потерпел неудачу
на некотором пути ( процесс возвратил код ошибки на выходе, или потерпел
крах, или тайм-аут операции). Если это состояние возникает, то причина
будет зарегистрирована в журнале, для дальнейшего использования.
Обратите внимание, что различные типы юнитов могут иметь ряд дополнительных
подсостояний, которые отображаются на пять обобщенных состояний юнитов,
описанных здесь.
Доступны следующие типы юнитов:
1. Service units, которые управляют демонами и процессами, из которых
они состоят. За деталями обращайтесь к systemd.service(5).
2. Socket units, которые инкапсулируют локальные IPC или сетевые сокеты
в системе, полезные при socket-based активации. За деталями об socket
units обращайтесь к systemd.socket(5), за деталями по socket-based
активации и другим формам активации обращайтесь к daemon(7).
3. Target units полезны для группировки юнитов или обеспечения хорошо
известных точек синхронизации в процессе загрузки, смотрите
systemd.target(5).
4. Device units представляют устройства ядра в systemd и могут быть
использованы для выполнения device-based активации. Более подробную
информацию смотрите в systemd.device(5).
5. Mount units управляют точками монтирования в файловой системе, за
деталями обращайтесь к systemd.mount(5).
6. Automount units обеспечивают возможности автомонтирования, для
монтирования файловых систем "по требованию", а также параллелизации
загрузки. Смотрите systemd.automount(5).
7. Snapshot units могут быть использованы для временного сохранения
состояний множества юнитов systemd, которые позже могут быть
восстановлены при активации сохраненного snapshot unit. За
дополнительной информацией обращайтесь к systemd.snapshot(5).
8. Timer units используются для запуска активации других юнитов
основываясь на таймерах. Вы можете найти детали в systemd.timer(5).
9. Swap units очень похожи на mount units и инкапсулируют разделы
или файлы подкачки памяти операционной системы. Они описаны в
systemd.swap(5).
10. Path units могут быт использованы для активации других сервисов
когда объекты файловой системы меняются или модифицируются.
Обращайтесь к systemd.path(5).
Юниты именуются как свои конфигурационные файлы. Некоторые юниты имеют
свою особенную семантику. Детальный список доступен в systemd.special(7).
systemd известны различные виды зависимостей, в том числе зависимости
требования положительные и отрицательные (например, Requires= и
Conflicts=), а также зависимости очередности (After= и Before=). NB:
зависимости очередности и требования ортогональны. Если только зависимость
требования существует между двумя юнитами (например, foo.service
требует bar.service), но не зависимость очередности (например, после
foo.service bar.service), и оба запрошены на запуск, то они будут
запускаться параллельно. Это общий шаблон, что обе зависимости требования
и очередности существуют между двумя юнитами. Также отметим, что
большинство зависимостей неявно создается и поддерживается systemd.
В большинстве случаев нет необходимости объявлять дополнительные
зависимости вручную, однако это можно сделать.
Прикладные программы и юниты (через зависимости) могут потребовать
изменения состояния юнитов. В systemd эти требования инкапсулируются
в 'jobs' и поддерживается в job очереди. Jobs могут успешно выполниться,
или могут потерпеть неудачу, их выполнение упорядочены согласно
зависимости очередности юнитов, на которую они были запланированы.
При загрузке systemd активизирует юнит типа target default.target, чья
работа заключается в активации загружаемых сервисов и других загружаемых
юнитов, потянув их с помощью зависимостей. Обычно имя этого юнита просто
псевдоним (ссылка) либо на graphical.target (для полнофункциональных
загрузок в пользовательский интерфейс) или на multi-user.target (для
ограниченной только консолью загрузки при использования во встроенных
или серверных средах, или им подобных; подмножество graphical.target).
Впрочем на усмотрение администратора оставлена возможность сделать его
в псевдонимом к любому другому юниту типа target. Подробнее об этих
юнитах типа target смотрите systemd.special(7).
Процессы потомки systemd помещаются в отдельный Linux группы управления
с именами как у юнитов, к которым они принадлежат в собственной иерархии
systemd.(смотрите cgroups.txt [1] для получения дополнительной информации
о группах управления, или коротко cgroups"). systemd использует это,
чтобы эффективно отслеживать процессы. Информация о группе управления
поддерживается в ядре, и доступна с помощью иерархии файловой системы
(под /sys/fs/cgroup/systemd/), или в таких инструментов, как ps(1)
(ps xawf -eo pid,user,cgroup,args особенно полезна, чтобы получить
список всех процессов и юнитов systemd, которым они принадлежат).
systemd в большой степени совместима с системой SysV init: SysV init
скрипты поддерживаются и просто читаются как файлы конфигурации
альтернативного (хотя и ограниченного) формата . Обеспечивается SysV
/dev/initctl интерфейс и доступна совместимая реализация различных
SysV клиентских инструментов. Кроме того, поддерживаются различные
устоявшиеся Unix функциональности, такие как /etc/fstab или базы
данных utmp.
systemd имеет минимальную систему трансакций : если требуется
запустить или выключить юнит, то он и все его зависимости будут
добавлены во временную трансакцию. Далее, следует проверка является
ли трансакция последовательной (является ли порядок всех юнитов не
зацикленным). Если это не так, systemd постарается исправить это,
и удалит из трансакции jobs, не являющиеся необходимыми,
что может избавить от зацикливания. Также, systemd пытается подавить
не являющиеся необходимыми jobs в трансакции, которые могут остановить
запущенный сервис. Наконец, проверяется, является ли jobs из трансакции
противоречивыми jobs, которые уже находятся очереди, и тогда возможно
трансакция будет прервана. Если все работает, и трансакция является
последовательной и сведено к минимуму ее влияние,то она объединяется со
всеми уже ожидающий обработки jobs и добавляется в очередь выполнения.
Фактически это означает, что до выполнения затребованной операции,
systemd будет проверять, что она имеет смысл, исправлять ее, если
возможно, и если она действительно не может работать отменит ее.
Systemd содержит встроенную реализацию различных задач, которые должны
быть выполнены как часть процесса загрузки. Например, устанавливает
имя хоста или конфигурирует петлевое устройство сети. Также настраивает
и монтирует различные файловые системы API, такие как /sys или /proc.
Для получения дополнительной информации о понятиях и идеях стоящих за
systemd, пожалуйста, обратитесь к Original Design Document[2].
Обратите внимание, что некоторые, но не все интерфейсы, предоставляемые
systemd охвачены Interface Stability Promise[3].
DIRECTORIES
Каталоги системных юнитов
системный администратор systemd читает конфигурацию юнитов из
различных каталогов. Пакеты, которые хотят установить файлы юнитов,
должны разместить их в каталог, возвращаемый командой
pkg-config systemd --variable=systemdsystemunitdir
Другие проверяемыми каталогами являются /usr/local/lib/systemd/system
и /usr/lib/systemd/system.
Пользовательская конфигурация всегда имеет приоритет.
pkg-config systemd --variable=systemdsystemconfdir возвращает
путь к каталогу системной конфигурации. Пакеты должны изменять
содержимое этих каталогов только командами enable и disable
инструмента systemctl(1).
Каталоги пользовательских юнитов
Подобные правила применяются для каталогов пользовательских юнитов.
Однако, находить юниты здесь следует по спецификации
XDG Base Directory [4]. Приложения должны поместить свои файлы юнитов
в каталог, возвращенный командой
pkg-config systemd --variable=systemduserunitdir. Глобальная
конфигурация выполнена в каталоге, о котором сообщает команда
pkg-config systemd --variable=systemduserconfdir. Команды enable
и disable инструмента systemctl(1) могут обращаться с обоими видами
юнитов глобальными (то есть для всех пользователей) и частными (для
одного пользователя) разрешая/запрещая их.
Каталоги скриптов SysV init
Местоположение каталогов скриптов SysV init варьируется между
дистрибутивами. Если systemd не может найти родной unit файл для
требуемого сервиса, он будет искать скрипт SysV init того же самого
имени (с удаленным суффиксом .service).
Каталог механизма ссылок SysV runlevel
Местоположение каталога механизма ссылок SysV runlevel различно
между дистрибутивами. systemd учитывает механизм ссылок, определяя,
должен ли сервис быть включен. Обратите внимание на то, что
service unit с встроенным unit конфигурационным файлом не может
быть запущен, при активизации его в механизме ссылок SysV runlevel.
SIGNALS
SIGTERM
После получения этого сигнала системный менеджер systemd
сериализует его состояние, перезапускает себя и десереализует
сохраненное состояние снова. В основном это эквивалентно:
systemctl daemon-reexec.
Пользовательский менеджер systemd запустит exit.target unit, когда
примет этот сигнал. В основном это эквивалентно:
systemctl --user start exit.target.
SIGINT
После получения этого сигнала системный менеджер systemd запустит
юнит ctrl-alt-del.target. В основном это эквивалентно:
systemctl start ctl-alt-del.target.
Пользовательский менеджер systemd обойдется с этим сигналом тем
же способом что и сигналом SIGTERM.
SIGWINCH
Когда будет получен этот сигнал, системный менеджер запустит
юнит kbrequest.target. В основном это эквивалентно:
systemctl start kbrequest.target.
Пользовательский менеджер systemd игнорирует этот сигнал.
SIGPWR
Когда будет получен этот сигнал, системный менеджер запустит
юнит sigpwr.target. В основном это эквивалентно:
systemctl start sigpwr.target.
SIGUSR1
Когда будет получен этот сигнал, системный менеджер будет
пытаться пересоединиться к шине D-Bus.
SIGUSR2
Когда будет получен этот сигнал, системный менеджер запишет в лог
целиком свое состояние в человеко читаемой форме. Записанные данные
будут такие же как выводимые командой: systemctl dump.
SIGHUP
Перезагрузка полностью конфигурации демона. В основном это
еквивалентно: systemctl daemon-reload.
SIGRTMIN+0
Входит в режим по умолчанию, запускает юнит default.target.
В основном это эквивалентно: systemctl start default.target.
SIGRTMIN+1
Входит в спасательный режим, запускает юнит rescue.target.
В основном это эквивалентно: systemctl isolate rescue.target.
SIGRTMIN+2
Входит в аварийный режим, запускает юнит emergency.service.
В основном это эквивалентно: systemctl isolate emergency.service.
SIGRTMIN+3
Останавливает машину, запускает юнит halt.target. В основном
это эквивалентно: systemctl start halt.target.
SIGRTMIN+4
Выключение питания компьютера, запускает юнит poweroff.target.
В основном это эквивалентно systemctl start poweroff.target.
SIGRTMIN+5
Перезапуск машины, запуск юнита reboot.target. В основном это
эквивалентно: systemctl start reboot.target.
SIGRTMIN+6
Перезапуск машины через kexec, запуск юнита kexec.target.
В основном это эквивалентно: systemctl start kexec.target.
SIGRTMIN+13
Немедленный останов машины.
SIGRTMIN+14
Немедленное отключение питания машины.
SIGRTMIN+15
Немедленная перезагрузка машины.
SIGRTMIN+16
Немедленная перезагрузка машины с kexec.
SIGRTMIN+20
Делает возможным вывод статусных сообщений на консоль, будь то
вызванная параметром systemd.show_status=1 в командной строке ядра.
SIGRTMIN+21
Отмена возможности вывода статусных сообщений на консоль, будь то
вызванная параметром systemd.show_status=0 в командной строке ядра.
ENVIRONMENT
$SYSTEMD_LOG_LEVEL
systemd читает log level из этой переменной окружения. Эта
настройка может быть переопределена с помощью опции --log-level=.
$SYSTEMD_LOG_TARGET
systemd читает целевой журнал из этой переменной окружения. Эта
настройка может быть переопределена с помощью опции --log-target=.
$SYSTEMD_LOG_COLOR
Управляет будет ли systemd выделять цветом важные журнальные
сообщения. Эта настройка может быть переопределена с помощью
опции --log-color=.
$SYSTEMD_LOG_LOCATION
Управляет будет ли systemd выводить номер строки в исходном коде
вместе с журнальными сообщениям. Это поведение может быть
переопределено с помощью опции --log-location=.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Пользовательский менеджер systemd использует эти переменные в
соответствии с XDG Base Directory спецификацией [4] что найти
ее конфигурацию.
$SYSTEMD_UNIT_PATH
Задает где systemd ищет файлы юнитов.
$SYSTEMD_SYSVINIT_PATH
Задает где systemd ищет скрипты SysV init.
$SYSTEMD_SYSVRCND_PATH
Задает где systemd ищет скрипты системы ссылок runlevel SysV init.
$LISTEN_PID, $LISTEN_FDS
Устанавливается systemd для контролируемых процессов во время
socket-based активации. Смотрите See sd_listen_fds(3) для
большей информации.
$NOTIFY_SOCKET
Устанавливается systemd для контролируемых процессов для
уведомлений о статусе и завершении запуска. Смотрите
See sd_notify(3) для большей информации.
KERNEL COMMAND LINE
Когда запущен в системной инстанции systemd разбирает несколько
аргументов командной строки ядра:
systemd.unit=
Переопределяет юнит, который активируется при загрузке. По
умолчанию это default.target. Это может быть использовано для
временной загрузки в другой загрузочный юнит, как например
rescue.target или emergency.service. Смотрите systemd.special(7)
для детальной информации об этих юнитах.
systemd.dump_core=
Принимает булевый аргумент. Если true, то systemd делает core
dump когда рушится. В противном случае core dump не создается.
По умолчанию true.
systemd.crash_shell=
Принимает булевский аргумент. Если true, то systemd порождает
shell, когда рушится. В противном случае shell не порождается. По
умолчанию false, из соображений безопасности, так как shell
не защищен никакой парольной аутентификацией.
systemd.crash_chvt=
Принимает аргумент целое число. Если положительное, то systemd
активирует заданный виртуальный терминал когда рушится. По
умолчанию -1.
systemd.confirm_spawn=
Принимает булевский аргумент. Если true то запрашивается
подтверждение когда порождается процесс. По умолчанию false.
systemd.show_status=
Принимает булевский аргумент. Если true, то выводит на консоль
в сжатом виде изменения статуса сервисов в течении загрузки. По
умолчанию true.
systemd.sysv_console=
Принимает булевский аргумент. Если true то вывод скрипты SysV init
будет направлен на консоль. По умолчанию true, но если quiet передан
как опция командной строки ядра, то в этом случае по умолчанию false.
systemd.log_target=, systemd.log_level=, systemd.log_color=,
systemd.log_location=
Управляет выводом в лог с тем же эффектом ка и
$SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR,
$SYSTEMD_LOG_LOCATION environment variables described above.
systemd.default_standard_output=, systemd.default_standard_error=
Управляет стандартным выводом/выводом ошибки для сервисов по
умолчанию с тем же эффектом как и аргументы командной строки
описанные выше --default-standard-output= и
--default-standard-error= соответственно.
SOCKETS AND FIFOS
/run/systemd/notify
Сокет уведомления состояния демона. Это сокет AF_UNIX datagram
используется для реализации логики уведомления демона, которое
осуществляется посредством sd_notify(3).
/run/systemd/logger
Используется внутренне юнитом systemd-logger.service для
соединения STDOUT и/или STDERR порожденных просессов с syslog
или буфером журналов ядра. Это AF_UNIX потоковый сокет.
/run/systemd/shutdownd
Используется внутренне инструментом shutdown(8) для выполнения
задержанного выключения. Это AF_UNIX datagram сокет.
/run/systemd/private
Предназначен для внутреннего использования в качестве канала связи
между systemctl (1) и systemd процессами. Это AF_UNIX потоковый сокет.
Этот интерфейс является частным systemd и не должен использоваться
во внешних проектах.
/dev/initctl
Ограниченная поддержка совместимости клиентского интерфейса SysV,
реализованная systemd-initctl.service unit. Это именованный канал
в файловой системе. Этот интерфейс является устаревшим и не должны
использоваться в новых приложениях.
SEE ALSO
systemctl(1), systemadm(1), systemd-notify(1), daemon(7), sd-daemon(7),
systemd.unit(5), systemd.special(5), pkg-config(1)
AUTHOR
Lennart Poettering
Developer
NOTES
1. cgroups.txt
http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
2. Original Design Document
http://0pointer.de/blog/projects/systemd.html
3. Interface Stability Promise
http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
4. XDG Base Directory specification
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
systemd 06/16/2011 SYSTEMD(1)
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |