The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

systemd (1)
  • >> systemd (1) ( Русские man: Команды и прикладные программы пользовательского уровня )
  • Ключ systemd обнаружен в базе ключевых слов.
  • 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)
    

    Поиск по тексту MAN-ов: 




      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor