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)