Vendor preset disabled что означает

Мне кажется лучше всего изучать написание юнитов с помощью просмотра уже подготовленных юнитов. Давайте посмотрим на один такой юнит — ssh.service.

Юнит SystemD — ssh.service

Статус службы

Для начала с помощью команды systemctl status ssh посмотрим статус этой службы:

alex@deb:~$ sudo systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-07-21 13:59:59 MSK; 5min ago Docs: man:sshd(8) man:sshd_config(5) Process: 10614 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 10615 (sshd) Tasks: 1 (limit: 2340) Memory: 1.1M CPU: 76ms CGroup: /system.slice/ssh.service └─10615 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

В этом выводе можно увидеть файл юнита — /lib/systemd/system/ssh.service. Также видно что включена автозагрузка службы — enabled. И фраза vendor preset: enabled — означает что служба поставляется со включенной автозагрузкой. Другими словами, при установке пакета ssh, сразу включится автозапуск этой службы.

Содержимое юнита

Давайте теперь посмотрим на содержимое юнита. Это можно сделать с помощью двух разных команд:

alex@s-deb:~$ cat /lib/systemd/system/ssh.service *** Этот вывод я пропущу, так как он аналогичен выводу следующей команды *** alex@s-deb:~$ systemctl cat ssh.service # /lib/systemd/system/ssh.service [Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service

Здесь мы видим 3 блока:

• [Unit] — здесь можно описать юнит, и указать ограничения на его запуск;
• [Service] — сюда добавляется информация, которая используется для запуска, работы и остановки службы;
• [Install] — в этом блоке описываются дополнительные условия для запуска или автозапуска службы.

Блок [Unit]

• Description — описание юнита;
• Documentation — источники документации;
• After — запускать юнит после запуска перечисленных юнитов, при этом не требуется чтобы эти юниты были запущены, этот параметр влияет только на очерёдность;
• Requires — в нашем примере нет этой опции, но про неё следует знать. Эта опция требует чтобы перечисленные юниты работали. Если они не будут работать, то и наш юнит не запустится;
• ConditionPathExists — эта опция проверяет наличия указанного файла. Восклицательный знак перед именем файла означает, что юнит запустится только в том случае, если этого файла в системе нет. Получается чтобы запретить запуск службы ssh достаточно создать файл /etc/ssh/sshd_not_to_be_run.

Блок [Service]

• EnvironmentFile — переменные окружения для службы и её процессов будут браться из указанного файла. Минус перед файлом (как в нашем случае -/etc/default/ssh) означает что файл может отсутствовать и это не приведёт к ошибке при запуске службы. Это можно использовать как файл с дополнительными настройками.
• ExecStartPre — здесь указывается дополнительная команда, которая выполняется перед запуском службы. Это можно использовать, например для подготовки окружения перед запуском.
• ExecStart — команда, которая запускает службу. Именно в этом параметре нужно указать главный исполняемый файл (утилиту или скрипт), ради которого мы создаём службу.
• ExecReload — здесь нужно указать которая выполнится при выполнении systemctl reload . А если утилита не умеет перечитывать свою конфигурацию, без перезагрузки, то можно опустить этот параметр. Параметров ExecStartPre, ExecStart, ExecReload может быть несколько, если нужно выполнить несколько команд.
• KillMode — указывает, как процессы службы должны завершаться. Существует несколько вариантов:
  • control-group — сигнал остановки будет послан всем процессам службы;
  • mixed — первый сигнал остановки будет послан главному процессу, а второй всем остальным процессам;
  • process — сигнал остановки будет послан только главному процессу, все остальные процессы (если они есть) останутся работать;
  • none — никому не будет отправлен сигнал остановки, служба будет выключена, но все процессы продолжат работать (настоятельно не рекомендуется);
  • on-failure — при ошибке;
  • on-success — при успехе (при корректном завершении службы);
  • no — никогда (по умолчанию);
  • always — всегда, то есть если ваша служба по каким-то причинам останавливается корректно, то этот параметр её перезапустит. Но это не сработает, если вы выполните (systemctl stop ).
  • simple или exec — они используются для запуска программы как службы. Этот тип стоит использовать, когда запускаемая программа не умеет сама запускаться в фоновом режиме. То есть запускается на переднем плане. Прервать выполнение такой программы можно с помощью комбинации клавиш Ctrl+C. При этом simple отрабатывает быстрее, но не следит за запуском исполняемого файла, указанного в ExecStart. А exec дожидается запуска исполнимого файла, и только после этого служба считается запущенной. Желательно использовать exec вместо simple, так как в simple служба может оказаться успешно запущенной, даже если исполнимый файл не смог запустится;
  • forking — этот тип следует использовать если запускаемое приложение умеет само запускаться в фоновом режиме. Можно использовать этот тип, если вы запускаете с помощью скрипта несколько процессов, которые умеют запускаться в фоне. То есть в ExecStart указан скрипт, а в скрипте запускаются фоновые процессы. В этом случае сам скрипт выполнится и завершится, а служба будет управлять запущенными фоновыми процессами;
  • oneshot — если подразумевается разовый запуск утилиты или скрипта, то подойдет этот тип. Служба такого типа никогда не будет запущенной. Вы запускаете службу, скрипт выполняется и служба останавливается;
  • dbus — если служба использует соединение D-Bus, то можно использовать этот тип службы. Когда служба запустится, то получит имя на шине D-Bus. Если это имя освободится, то служба будет считаться неисправной и все процессы службы начнут завершатся. Про D-Bus также будет написана отдельная статья;
  • notify — поведение похоже на exec, но дополнительно ожидается, что служба отправит сигнал готовности после своего запуска;
  • idle — система отложит выполнение двоичного файла службы до окончания запуска остальных (более срочных) задач, максимум на 5 секунд. В остальном поведение аналогично simple.

  Блок [Install]

  • WantedBy — если мы включим автозагрузку этой службы (с помощью команды systemctl enable ), то она должна запуститься при загрузке мультипользовательского режима (multi-user.target). Про таргеты и загрузочные таргеты будет следующая статья.
  • Alias — псевдоним службы. Указание псевдонима приведёт к тому, что к службе можно будет обратиться ещё и по имени псевдонима. Например, вместо ssh.service можно использовать sshd.service (systemctl status sshd.service).

  Дополнительные опции

  В юните SystemD — ssh.service использовались далеко не все из возможных опций. Вот некоторые опции, которые можно использовать для создания своих служб (в блоке [Service]):

  • User — с помощью этого параметра можно указать пользователя (username или uid), от чьего имени будут запущены процессы службы. То есть этот пользователь будет запускать исполняемый файл, указанный в ExecStart.
  • ExecStop — команда, которую нужно выполнить при остановке службы (systemctl stop ).
  • KillSignal — здесь можно указать сигнал остановки процессов. А если этот параметр не указать, то будет использован сигнал SIGTERM. Про сигналы, которые можно посылать процессам, я напишу позже.
  • LimitNOFILE — указывается максимальное число открытых файлов, которые смогут открыть процессы службы.
  • LimitCPU — можем задать максимальное количество процессорного времени в секундах. Когда лимит будет израсходован, служба завершится с ошибкой.
  • LimitRSS — лимит потребления памяти в байтах. При достижении лимита служба завершится с ошибкой.
  • LimitNPROC — максимальное число процессов в службе.
  • Nice — уровень любезности запускаемых процессов службой. Любезность (Nice) — это параметр обратный приоритету. Чем выше Nice, тем ниже приоритет у процесса, и тем меньше он нагружает процессор. Может быть от -20 (самый приоритетный) до 19 (наименьший приоритет).

  Итог

  Это не все опции, на самом деле их очень много. Для тех кто хочет во всём этом разобраться дам несколько ссылок на официальную документацию SystemD (на английском):

  • Настройка юнитов — описывают сами юниты, их типы, их расположение и приоритет. А также здесь описываются параметры, которые можно использовать в блоке [Unit] и [Install].
  • Управление выполнением юнитов (не только служб) — описывают параметры, с помощью которых мы можем контролировать запускаемые процессы. Эти параметры принадлежат блоку [Service]. Это лимиты, пользователи, параметры безопасности, переменные окружения и тому подобное.

  Управление сервисами и юнитами systemd с помощью systemctl

  Systemd – это система инициализации и системный менеджер, который становится новым стандартом для Linux-машин. Споры о продуктивности systemd по сравнению с традиционными системами инициализации SysV ведутся до сих пор, тем не менее, эту систему планируют внедрить большинство дистрибутивов, а многие уже сделали это.

  Изучение инструментов и демонов systemd и умение работать с ними поможет вам лучше оценить мощность, гибкость и другие возможности системы или, по крайней мере, справиться с минимальными трудностями.

  Данный мануал научит вас работать с командой systemctl, главным инструментом управления системы инициализации systemd. Вы узнаете, как управлять сервисами, проверять состояние и работать с конфигурационными файлами.

  Управление сервисами

  Основная цель init-системы – инициализировать компоненты, которые должны запускаться после загрузки ядра Linux (традиционно они называются «пользовательскими» компонентами). Система инициализации также используется для управления сервисами и демонами сервера. Имея это в виду, начнем знакомство с systemd с простых операций управления сервисами.

  В systemd целью большинства действий являются юниты – ресурсы, которыми systemd может управлять. Юниты делятся на категории по типам ресурсов, которые они представляют. Юниты определяются в так называемых юнит-файлах. Тип каждого юнита можно определить по суффиксу в конце файла.

  Для задач управления сервисами предназначены юнит-файлы с суффиксом .service. Однако в большинстве случаев суффикс .service можно опустить, так как система systemd достаточно умна, чтобы без суффикса определить, что нужно делать при использовании команд управления сервисом.

  Запуск и остановка сервиса

  Чтобы запустить сервис systemd, используйте команду start. Если вы работаете не в сессии пользователя root, вам нужно использовать sudo, поскольку эта команда повлияет на состояние операционной системы:

  sudo systemctl start application.service

  Как уже говорилось ранее, systemd знает, что для команд управления сервисами нужно искать файлы *.service, поэтому эту команду можно ввести так:

  sudo systemctl start application

  Вышеуказанный формат можно использовать в повседневной работе, но в мануале для ясности мы будем использовать суффикс .service.

  Чтобы остановить сервис, достаточно ввести команду stop:

  sudo systemctl stop application.service

  Перезапуск и перезагрузка

  Чтобы перезапустить сервис, используйте restart:

  sudo systemctl restart application.service

  Если указанное приложение может перезагрузить свои конфигурационные файлы (без перезапуска), можно использовать reload:

  sudo systemctl reload application.service

  Если вы не знаете, может ли сервис перезагрузить свои файлы, используйте команду reload-or-restart. Она перезагрузит сервис, а если это невозможно – перезапустит его.

  sudo systemctl reload-or-restart application.service

  Включение и отключение сервисов

  Приведенные выше команды необходимы при работе с сервисом в текущей сессии. Чтобы добавить сервис в автозагрузку systemd, его нужно включить.

  Для этого существует команда enable:

  sudo systemctl enable application.service

  Это создаст символическую ссылку на копию файла сервиса (обычно в /lib/systemd/system или /etc/systemd/system) в точке на диске, где systemd ищет файлы для автозапуска (обычно /etc/systemd/system/some_target.target.want, подробнее об этом – дальше в руководстве).

  Чтобы убрать сервис из автозагрузки, нужно ввести:

  sudo systemctl disable application.service

  Это удалит символическую ссылку, после этого сервис перестанет запускаться автоматически.

  Имейте в виду, что включение сервиса не запускает его в текущей сессии. Если вы хотите запустить сервис и включить его в автозагрузку, вам нужно запустить команды start и enable.

  Проверка состояния сервиса

  Чтобы проверить состояние сервиса, введите:

  systemctl status application.service

  Эта команда выведет состояниесервиса, иерархию групп и первые несколько строк лога.

  Например, при проверке состояния сервера Nginx вы можете увидеть такой вывод:

  nginx.service — A high performance web server and a reverse proxy server
  Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
  Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
  Main PID: 495 (nginx)
  CGroup: /system.slice/nginx.service
  ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
  └─496 nginx: worker process
  Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server.
  Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

  Это предоставляет обзор текущего состояния приложения, уведомляет вас о любых проблемах и любых действиях, которые могут потребоваться в дальнейшем.

  Существуют также методы проверки конкретных состояний. Например, чтобы проверить, активен ли данный юнит (запущен ли он), вы можете использовать команду is-active:

  systemctl is-active application.service

  Это отобразит текущее состояние юнита, обычно это active или inactive. Код завершения будет «0», если юнит активен, что упрощает процесс анализа.

  Чтобы узнать, включен ли юнит, вы можете использовать команду is-enabled:

  systemctl is-enabled application.service

  Эта команда сообщит, включен ли сервис, и снова определит код завершения как «0» или «1» в зависимости от результата.

  Третья команда позволяет определить, находится ли юнит в состоянии сбоя. Это указывает на то, что возникла проблема с запуском рассматриваемого юнита:

  systemctl is-failed application.service

  Команда вернет active, если юнит работает правильно, и failed, если случилась ошибка. Если юнит был остановлен намеренно, команда может вернуть unknown или inactive. Код завершения «0» означает, что произошел сбой, а «1» указывает на любое другое состояние.

  Обзор состояния системы

  Ранее мы рассмотрели команды, необходимые для управления отдельными сервисами, но они не очень полезны для изучения текущего состояния системы. Существует несколько команд systemctl, которые предоставляют эту информацию.

  Просмотр списка текущих юнитов

  Чтобы запросить список текущих юнитов systemd, используйте команду list-units:

  Эта команда покажет список всех юнитов, которые в настоящее время существуют в системе systemd. Результат будет выглядеть примерно так:

  UNIT LOAD ACTIVE SUB DESCRIPTION
  atd.service loaded active running ATD daemon
  avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
  dbus.service loaded active running D-Bus System Message Bus
  dcron.service loaded active running Periodic Command Scheduler
  dkms.service loaded active exited Dynamic Kernel Modules System
  getty@tty1.service loaded active running Getty on tty1
  . . .

  В выводе есть такие столбцы:

  • UNIT – название юнита systemd.
  • LOAD – сообщает, была ли конфигурация юнита обработана systemd. Конфигурация загруженных юнитов хранится в памяти.
  • ACTIVE – сводное состояние юнита. Обычно это позволяет быстро определить, успешно ли запущен текущий юнит.
  • SUB: состояние более низкого уровня, которое сообщает подробную информацию об устройстве. Это часто зависит от типа юнита, состояния и фактического метода, в котором запущен юнит.
  • DESCRIPTION – краткое описание функций юнита.

  Поскольку команда list-units показывает по умолчанию только активные юниты, все вышеперечисленные записи будут показывать loaded в столбце LOAD и active в столбце ACTIVE. Такой формат является поведением systemctl по умолчанию при вызове без дополнительных команд, поэтому вы увидите то же самое, если вы вызываете systemctl без аргументов:

  С помощью systemctl можно запрашивать различную информацию путем добавления флагов. Например, чтобы увидеть все юниты, которые загрузила (или попыталась загрузить) система systemd, независимо от того, активны ли они в данный момент, вы можете использовать флаг -all:

  systemctl list-units —all

  Эта команда сообщит о юнитах, которые загрузила или попыталась загрузить система systemd, независимо от их текущего состояния. После запуска некоторые юниты становятся неактивными, а юниты, которые пыталась загрузить systemd, не были найдены на диске.

  Вы можете использовать другие флаги для фильтрации результатов. Например, флаг –state= можно использовать для определения состояний LOAD, ACTIVE или SUB. Флаг –all нужно оставить, чтобы система отображала неактивные юниты:

  systemctl list-units —all —state=inactive

  Еще один популярный фильтр – это –type=. Он позволяет отфильтровать юниты по типу. К примеру, чтобы запросить только активные юниты, можно ввести:

  systemctl list-units —type=service

  Список юнит-файлов

  Команда list-units отображает только юниты, которые система systemd попыталась обработать и загрузить в память. Поскольку systemd избирательно читает только те юнит-файлы, которые кажутся ей необходимыми, список не будет включать все доступные юнит-файлы. Чтобы просмотреть список всех доступных юнит-файлов (включая те, что systemd не пыталась загрузить), используйте команду list-unit-files.

  Юниты являются представлениями ресурсов, о которых знает systemd. Поскольку systemd не обязательно читает все определения юнитов, она представляет только информацию о самих файлах. Вывод состоит из двух столбцов: UNIT FILE и STATE.

  UNIT FILE STATE
  proc-sys-fs-binfmt_misc.automount static
  dev-hugepages.mount static
  dev-mqueue.mount static
  proc-fs-nfsd.mount static
  proc-sys-fs-binfmt_misc.mount static
  sys-fs-fuse-connections.mount static
  sys-kernel-config.mount static
  sys-kernel-debug.mount static
  tmp.mount static
  var-lib-nfs-rpc_pipefs.mount static
  org.cups.cupsd.path enabled
  . . .

  Обычно столбец STATE содержит значения enabled, disabled, static или masked. В этом контексте static означает, что в юнит-файле нет раздела install, который используется для включения юнита. Таким образом, эти юниты невозможно включить. Обычно это означает, что юнит выполняет одноразовое действие или используется только как зависимость другого юнита и не должен запускаться сам по себе.

  Подробнее о значении masked вы узнаете далее.

  Управление юнитами

  Теперь вы знаете, как работать с сервисами и отображать информацию о юнитах и юнит-файлах, о которых знает systemd. Получить более конкретную информацию о юнитах можно с помощью некоторых дополнительных команд.

  Отображение юнит-файла

  Чтобы отобразить юнит-файл, который загрузила systemd, вы можете использовать команду cat (была добавлена в версии systemd 209). Например, чтобы увидеть юнит-файл демона планирования atd, можно ввести:

  systemctl cat atd.service
  [Unit] Description=ATD daemon
  [Service] Type=forking
  ExecStart=/usr/bin/atd
  [Install] WantedBy=multi-user.target

  На экране вы увидите юнит-файл, который известен текущему запущенному процессу systemd. Это может быть важно, если вы недавно изменяли файлы модулей или если вы переопределяете некоторые параметры в фрагменте юнит-файла (об этом поговорим позже).

  Отображение зависимостей

  Чтобы просмотреть дерево зависимостей юнита, используйте команду:

  systemctl list-dependencies sshd.service

  Она отобразит иерархию зависимостей, с которыми системе необходимо иметь дело, чтобы запустить этот юнит. Зависимости в этом контексте – это те юниты, которые требуются для работы других юнитов, которые находятся выше в иерархии.

  sshd.service
  ├─system.slice
  └─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
  . . .

  Рекурсивные зависимости отображаются только для юнитов .target, которые указывают состояния системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг –all.

  Чтобы показать обратные зависимости (юниты, зависящие от указанного элемента), вы можете добавить в команду флаг –reverse. Также полезными являются флаги –before и –after, они отображают юниты, которые зависят от указанного юнита и запускаются до или после него.

  Проверка свойств юнита

  Чтобы увидеть низкоуровневые свойства юнита, вы можете использовать команду show. Это отобразит список свойств указанного юнита в формате ключ=значение.

  systemctl show sshd.service
  Id=sshd.service
  Names=sshd.service
  Requires=basic.target
  Wants=system.slice
  WantedBy=multi-user.target
  Conflicts=shutdown.target
  Before=shutdown.target multi-user.target
  After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
  Description=OpenSSH server daemon
  . . .

  Чтобы отобразить одно из свойтсв, передайте флаг –р и укажите имя свойства. К примеру, чтобы увидеть конфликты юнита sshd.service, нужно ввести:

  systemctl show sshd.service -p Conflicts
  Conflicts=shutdown.target

  Маскировка юнитов

  Systemd может блокировать юнит (автоматически или вручную), создавая симлинк на /dev/null. Это называется маскировкой юнитов и выполняется командой mask:

  sudo systemctl mask nginx.service

  Теперь сервис Nginx не будет запускаться автоматически или вручную до тех пор, пока включена маскировка.

  Если вы проверите list-unit-files, вы увидите, что сервис отмечен как masked:

  systemctl list-unit-files
  . . .
  kmod-static-nodes.service static
  ldconfig.service static
  mandb.service static
  messagebus.service static
  nginx.service masked
  quotaon.service static
  rc-local.service static
  rdisc.service disabled
  rescue.service static
  . . .

  Если вы попробуете запустить сервис, вы получите такое сообщение:

  sudo systemctl start nginx.service
  Failed to start nginx.service: Unit nginx.service is masked.

  Чтобы раскрыть (разблокировать) юнит и сделать его доступным, используйте unmask:

  sudo systemctl unmask nginx.service

  Это вернет сервис в его прежнее состояние.

  Редактирование юнит-файлов

  Хотя конкретный формат юнит-файлов не рассматривается в данном руководстве, systemctl предоставляет встроенные механизмы для редактирования и изменения юнит-файлов. Эта функциональность была добавлена в systemd версии 218.

  Команда edit по умолчанию открывает сниппет юнит-файла:

  sudo systemctl edit nginx.service

  Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение юнита. В каталоге /etc/systemd/system будет создан каталог, который содержит имя устройства с суффиксом .d. Например, для nginx.service будет создан каталог nginx.service.d.

  Внутри этого каталога будет создан сниппет с именем override.conf. Когда юнит загружается, systemd объединит в памяти сниппет для переопределения с остальным юнит-файлом. Директивы сниппета будут иметь приоритет над теми, что указаны в исходном юнит-файле.

  Если вы хотите отредактировать весь юнит-файл вместо создания сниппета, вы можете передать флаг –full:

  sudo systemctl edit —full nginx.service

  Это загрузит текущий юнит-файл в редактор, где его можно будет изменить. Когда редактор закроется, измененный файл будет записан в /etc/systemd/system и будет иметь приоритет над определением юнита системы (обычно он находится где-то в /lib/systemd/system).

  Чтобы удалить все сделанные вами дополнения, удалите каталог конфигурации .d или измененный файл сервиса из /etc/systemd/system. Например, чтобы удалить сниппет, можно ввести:

  sudo rm -r /etc/systemd/system/nginx.service.d

  Чтобы удалить полный отредактированный файл, введите:

  sudo rm /etc/systemd/system/nginx.service

  После удаления файла или каталога нужно перезагрузить процесс systemd, чтобы система больше не пыталась ссылаться на эти файлы и вернулась к использованию системных копий. Для этого введите:

  sudo systemctl daemon-reload

  Изменение уровней запуска

  Цели – это специальные юнит-файлы, которые описывают уровни системы или точки синхронизации. Как и другие юниты, файлы целей можно определить по суффиксу. В данном случае используется суффикс .target. Сами по себе цели ничего не делают, вместо этого они используются для группировки других юнитов.

  Цели можно использовать, чтобы привести систему в определенное состояние. Подобным образом другие системы инициализации используют уровни запуска. Они используются как ссылки, когда доступны определенные функции, что позволяет указать желаемое состояние вместо настройки отдельных юнитов, необходимых для создания этого состояния.

  Например, есть цель swap.target, которая используется для того, что чтобы сообщить, что swap готов к использованию. Юниты, которые являются частью этого процесса, могут синхронизироваться с этой целью при помощи директив WantedBy= или RequiredBy=. Юниты, которым нужен своп, могут указывать это условие через спецификации Wants=, Requires= или After=.

  Проверка и настройка целей по умолчанию

  Процесс systemd имеет цель по умолчанию, которую он использует при загрузке системы. Обеспечение ряда зависимостей этой единственной цели приводит систему в желаемое состояние. Чтобы найти цель по умолчанию, введите:

  systemctl get-default
  multi-user.target

  Если вы хотите установить другую цель по умолчанию, вы можете использовать set-default. Например, если у вас установлен графический рабочий стол и вы хотите, чтобы система загружала его по умолчанию, вы можете соответствующим образом изменить цель:

  sudo systemctl set-default graphical.target

  Список доступных целей

  Просмотреть список доступных целей можно с помощью команды:

  systemctl list-unit-files —type=target

  В отличие от уровней запуска, одновременно можно включать несколько целей. Активная цель указывает, что systemd будет пытаться запустить все юниты, привязанные к этой цели, и не попытается их отключить. Чтобы увидеть все активные цели, введите:

  systemctl list-units —type=target

  Изоляция целей

  Можно запустить все юниты, связанные с целью, и остановить все юниты, которые не являются частью дерева зависимостей. Для этого используется команда isolate. Она похожа на изменение уровня запуска в других системах инициализации.

  Например, если вы работаете в графической среде, где активна цель graphical.target, вы можете отключить графическую систему и перевести систему в состояние многопользовательской командной строки, изолировав multi-user.target. Поскольку graphical.target зависит от multi-user.target, но не наоборот, все графические юниты будут остановлены.

  Вы можете взглянуть на зависимости изолируемой цели, прежде чем выполнять эту процедуру, чтобы убедиться, что вы не останавливаете жизненно важные сервисы:

  systemctl list-dependencies multi-user.target

  Если вас все устраивает, можете изолировать цель:

  sudo systemctl isolate multi-user.target

  Сокращения

  Существуют цели, определенные для важных событий, таких как выключение или перезагрузка. systemctl также предлагает несколько сокращений для быстрого вызова.

  К примеру, чтобы перевести систему в режим отладки, можно ввести просто rescue вместо isolate rescue.target:

  sudo systemctl rescue

  Это обеспечит дополнительную функциональность – оповестит всех пользователей системы о событии.

  Чтобы остановить систему, вы можете использовать команду halt:

  sudo systemctl halt

  Чтобы начать полное завершение работы, вы можете использовать команду poweroff:

  sudo systemctl poweroff

  Перезапуск можно начать с помощью команды reboot:

  sudo systemctl reboot

  Эти команды сообщат пользователям системы о событиях, чего не сделает стандартная команда. Обратите внимание, большинство машин используют более короткие команды для этих операций, чтобы они работали правильно с systemd.

  Например, чтобы перезагрузить систему, вы можете ввести просто:

  Заключение

  Теперь вы знакомы с основными механизмами systemctl и знаете, как управлять системой инициализации с помощью этого инструмента.

  Хотя systemctl работает в основном с процессом systemd, в системе systemd есть другие компоненты, которые контролируются другими утилитами. К примеру, для управления логированием и пользовательскими сеансами используются отдельные демоны и утилиты (journald/journalctl и logind/loginctl соответственно).

  systemctl status shows vendor preset: disabled

  Could someone please clarify what «vendor preset : disable» means? This option is visible after enabling a package in RHEL7.

  66.5k 35 35 gold badges 115 115 silver badges 250 250 bronze badges

  asked Sep 10, 2018 at 16:28

  609 1 1 gold badge 9 9 silver badges 18 18 bronze badges

  2 Answers 2

  If you see a Vendor preset: Disabled, it means when the service first installs it will be disabled on start up and will have to be manually started. If you want the service to start up automatically with boot up, all it takes is to change it’s start up setting with systemctl enable , example: systemctl enable httpd .

  ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2018-09-10 09:29:16 MDT; 1h 3min ago Docs: man:httpd(8) man:apachectl(8) Process: 6917 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS) Main PID: 1261 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─1261 /usr/sbin/httpd -DFOREGROUND ├─6936 /usr/sbin/httpd -DFOREGROUND ├─6937 /usr/sbin/httpd -DFOREGROUND ├─6938 /usr/sbin/httpd -DFOREGROUND ├─6939 /usr/sbin/httpd -DFOREGROUND └─6940 /usr/sbin/httpd -DFOREGROUND Sep 10 09:28:51 localhost systemd[1]: Starting The Apache HTTP Server. Sep 10 09:29:16 localhost systemd[1]: Started The Apache HTTP Server. Sep 10 10:21:02 localhost systemd[1]: Reloaded The Apache HTTP Server. 

  Похожие публикации:

  1. Btrfs или ext4 synology что выбрать
  2. Зачем а главное зачем
  3. Как запустить java файл через командную строку
  4. Как сохранить listbox в файл c