Как использовать Systemctl для управления службами Systemd и юнитами


Оглавление

Введение

1. Управление службами

1.1 Запуск и остановка служб

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

1.3 Включение и отключение служб

1.4 Символ @ («собака») в именах служб

1.5 Проверка состояния служб

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

2.1 Список текущих юнитов

2.2 Вывод списка всех файлов юнитов

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

3.1 Показ файла юнита

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

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

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

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

5. Настройка состояния системы (уровень запуска) с помощью целей

5.1 Получение и установка дефолтной цели

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

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


5.4 Использование ярлыков для важных событий

Заключение


Источники:

Введение

Systemd – это система инициализации (init system) и системный менеджер, который получил широкое распространение и становится новым стандартом для Linux-машин. Хотя существуют обоснованные сомнения в том, является ли systemd улучшением по сравнению с традиционными системами инициализации SysV, большинство дистрибутивов уже перешли на systemd, либо планируют это сделать.

Коротко говоря, systemd отвечает за работу с процессами: запуск, остановку, проверку статуса, перезагрузка конфигурации и другое. Т.е. это очень важный аспект ОС, который нужно понимать и уметь им пользоваться. Если вам нужно проверить статус (работает или остановлена, успешно запущена или вылетела с ошибкой) службы, добавить службу в автозагрузку или убрать из автозагрузки, проверить список служб в автозагрузке, проверить свойства загружаемой службы или увидеть причины ошибки – то вы обращаетесь к systemd.

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

В этом руководстве мы обсудим команду systemctl, которая является центральным инструментом управления для контроля системы инициализации (init). Мы рассмотрим, как управлять сервисами, проверять состояния, изменять состояния системы и работать с файлами конфигурации. Мы охватим вопросы, как управлять службами, проверять статусы, изменять состояния системы и работать с конфигурационными файлами.

Обратите внимание: несмотря на то, что systemd стала стандартной системой инициализации для многих дистрибутивов Linux, она не реализована повсеместно во всех дистрибутивах. По мере прохождения этого руководства, если ваш терминал выводит ошибку bash: systemctl не установлен, (bash: systemctl is not installed), то вероятно, на вашем компьютере установлена другая система инициализации.

Управление службами

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

В systemd целью (объектами) большинства действий являются «юниты» (units), которые представляют собой ресурсы, которыми systemd знает как управлять. Юниты классифицируются по типу ресурса, который они представляют, и определяются файлами, известными как файлы юнитов. Тип каждого юнита может быть определён по суффиксу в конце файла.

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

Запуск и остановка служб

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

sudo systemctl start приложение.service

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

sudo systemctl start приложение

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

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


sudo systemctl stop приложение.service

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

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

sudo systemctl restart приложение.service

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

sudo systemctl reload приложение.service

Если вы не знаете, есть ли у службы функциональность для перезагрузки конфигурации, вы можете выполнить команду reload-or-restart. Она перезагрузит конфигурацию, если приложение поддерживает это. В противном случае она перезапустит службу, чтобы была подхвачена новая конфигурация:

sudo systemctl reload-or-restart приложение.service

Включение и отключение служб

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

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

sudo systemctl enable приложение.service

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

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

sudo systemctl disable приложение.service

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

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

systemctl enable --now apache2.service

Приведённая команда добавить веб-сервер Apache в автозагрузку и немедленно запустит его.

Переключатель --now работает с командами enable, disable и mask, соответственно для немедленного запуска, остановки или маскировки юнита, без ожидания следующей загрузки.

Символ @ («собака») в именах служб

Некоторые имена юнитов содержат символ @ (т.е. name@string.service): это означает, что они являются экземплярами юнита-шаблона, чьё действительное имя не содержит часть, которая в условном примере обозначена как string (т.е. name@.service). string называется идентификатором экземпляра и аналогична аргументу, который передается юниту-шаблону при вызове с помощью команды systemctl: в файле юнита он будет заменять спецификатор %i.

Для большей точности работы, перед попыткой создать экземпляр name@.suffix юнита-шаблона, systemd действительно ищет юнит с точным именем файла name@string.suffix, даже не смотря на то, что такие «конфликты» довольно редки, так как большинство файлов юнитов, содержащих знак @, подразумевают использование шаблонов. Кроме того, если юнит-шаблон вызывается без идентификатора экземпляра, ничего не получится, так как спецификатор %i не может быть подставлен.

К примеру, в файле юнита OpenVPN:

systemctl cat openvpn-server@server.service

содержится строка:


ExecStart=/usr/bin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf

В этой строке виден спецификатор %i, при его замене получится имя файла логов и файла конфигурации.

Используя различные значения string, можно добиться настройки автозапуска OpenVPN с различными конфигурационными файлами. Например:

systemctl enable openvpn-server@port_tcp_443

Этой командой служба OpenVPN будет добавлена в автозапуск, при этом она будет запускаться с конфигурационным файлом /etc/openvpn/server/port_tcp_443.conf. Используя такой подход, можно настроить автозапуск одной и той же службы с разными конфигурациями. Например, OpenVPN на разных портах.

Многие службы поддерживают модель шаблоны-экземпляры. К примеру, Apache2:

systemctl enable apache2@test

Эта команда приведёт к тому, что значение переменной окружения APACHE_CONFDIR будет установлено на /etc/apache2-test.

Проверка состояния служб

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

systemctl status приложение.service

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

Например, при проверке состояния веб-сервера Apache вы можете увидеть вывод следующим образом:

● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; disabled; vendor preset: disabled)
   Active: active (running) since Mon 2018-04-30 08:11:26 MSK; 11s ago
  Process: 2650 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 2661 (apache2)
    Tasks: 7 (limit: 4580)
   Memory: 31.1M
   CGroup: /system.slice/apache2.service
           ├─2661 /usr/sbin/apache2 -k start
           ├─2662 /usr/sbin/apache2 -k start
           ├─2663 /usr/sbin/apache2 -k start
           ├─2664 /usr/sbin/apache2 -k start
           ├─2665 /usr/sbin/apache2 -k start
           ├─2666 /usr/sbin/apache2 -k start
           └─2667 /usr/sbin/apache2 -k start

апр 30 08:11:25 HackWare systemd[1]: Starting The Apache HTTP Server...
апр 30 08:11:26 HackWare apachectl[2650]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
апр 30 08:11:26 HackWare systemd[1]: Started The Apache HTTP Server.

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

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

systemctl is-active приложение.service

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

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

systemctl is-enabled приложение.service

Будет выведено enabled или disabled, и снова код выхода будет установлен на «0» или «1» в зависимости от ответа на вопрос команды.

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

systemctl is-failed приложение.service

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

Следующая команда покажет сразу все завершившиеся неудачей юниты:

systemctl --failed

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

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

Список текущих юнитов

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

systemctl list-units

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

Вывод имеет следующие столбцы:

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

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

systemctl

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

systemctl list-units --all

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

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

systemctl list-units --all --state=inactive

Другим распространенным фильтром является фильтр --type=. Мы можем сказать systemctl отображать только те юниты, которые нас интересуют. Например, чтобы видеть только активные юниты служб, мы можем использовать:

systemctl list-units --type=service

или:

systemctl --type=service

Предыдущая команда покажет только активные службы, для вывода информации о всех службах добавьте ключ --all:

systemctl --type=service --all

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

systemctl list-units --type=service --state=СТАТУС

или:

systemctl --type=service --state=СТАТУС

В качестве СТАТУСа могут быть значения:

  • active
  • inactive
  • running
  • exited
  • dead
  • loaded
  • not-found
  • plugged
  • mounted
  • waiting
  • listening

Например, вывод служб, которые завершили свою работу:

systemctl --type=service --state=exited

Вывод служб, которые запущены в данный момент:

systemctl list-units --type=service --state=running

Или:


systemctl --type=service --state=running

Вывод списка всех файлов юнитов

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

systemctl list-unit-files

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

Если вы хотите посмотреть только юниты, добавленные в автозагрузку, то используйте следующую конструкцию:

systemctl list-unit-files | grep enabled

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

Чуть ниже мы рассмотрим, что означает «masked».

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

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

Показ файла юнита

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

systemctl cat apache2.service

Будет показано что-то вроде:

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
Environment=APACHE_STARTED_BY_SYSTEMD=true
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl stop
ExecReload=/usr/sbin/apachectl graceful
PrivateTmp=true
Restart=on-abort

[Install]
WantedBy=multi-user.target

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

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

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

systemctl list-dependencies ssh.service

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

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

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

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

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

systemctl show sshd.service

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

systemctl show ssh.socket -p Conflicts

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

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

sudo systemctl mask nginx.service

Это предотвратит запуск службы Nginx, автоматически или вручную, до тех пор, пока она замаскирована.

Если вы проверите list-unit-files, вы увидите, что служба теперь отображается как masked (замаскированная):

systemctl list-unit-files

Если вы попытаетесь запустить службу, вы увидите следующее сообщение:

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 ssh.socket

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

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

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

sudo systemctl edit --full ssh.socket

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

Для изменения файла откроется редактор joe или vim (в зависимости того, который выбран по умолчанию для вашего дистрибутива). Поэтому рекомендуется ознакомиться с Основами использования Joe’s Own Editor.

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

sudo rm -r /etc/systemd/system/ssh.socket.d

Для удаления полного модифицированного файла юнита, можно было бы напечатать:

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

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

sudo systemctl daemon-reload

Настройка состояния системы (уровень запуска) с помощью целей

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

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

Например, есть swap.target, который используется для указания того, что swap готов к использованию. Юниты, которые являются частью этого процесса, могут синхронизироваться с этой целью, указывая в своей конфигурации, что они WantedBy= или RequiredBy= цель swap.target. Юниты, для которых требуется файл подкачки, могут указывать это условие, используя спецификации 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 попытался запустить все юниты, привязанные к цели, и не попытался снова их отключить (teardown). Чтобы увидеть все активные цели, введите:

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 вместо изолирования rescue.target:

sudo systemctl rescue

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

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

sudo systemctl halt

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

sudo systemctl poweroff

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

sudo systemctl reboot

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

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

sudo reboot

В чём разница между «systemctl reboot» и «reboot», а также «systemctl poweroff» и «poweroff»

Команды halt, poweroff, reboot реализованы для того, чтобы сохранить базовую совместимость с исходными командами SysV. Глаголы

  • systemctl halt
  • systemctl poweroff
  • systemctl reboot

обеспечивают ту же функциональность с некоторыми дополнительными функциями.

То есть reboot это теперь тоже systemctl. В этом можно убедиться:

which reboot
/usr/sbin/reboot

file /usr/sbin/reboot
/usr/sbin/reboot: symbolic link to /bin/systemctl

То есть команда reboot на самом деле является символической ссылкой на systemctl.

В свою очередь команда

systemctl reboot

является сокращением для

systemctl start reboot.target --job-mode=replace-irreversibly --no-block

То есть

reboot

это в точности то же самое что и

systemctl reboot

а также

systemctl start reboot.target --job-mode=replace-irreversibly --no-block

Сказанное справедливо для дистрибутивов, которые перешли на systemd (например, это Arch Linux, всё семейство Debian, включая Ubuntu). То есть для большинства современных дистрибутивов, кроме тех, на которых остался SysV.

В некоторых случаях команда reboot не срабатывает — подробности смотрите в статье Ошибка «Failed to talk to init daemon». В этом случае для перезагрузки компьютера необходимо добавить опцию -f:

reboot -f

Команда для выключения следующая:

poweroff -f

Если даже эти команды не помогли, то используйте варианты с двойной опцией -f.

Чтобы выключить компьютер выполните:

poweroff -f -f

Или перезагрузите компьютер командой:

reboot -f -f

Опция -f означает принудительную немедленную остановку, выключение или перезагрузку. При указании один раз это приводит к немедленному, но чистому завершению работы системным менеджером. Если указано дважды, это приводит к немедленному завершению работы без обращения к системному менеджеру.

При использовании опции -f с systemctl halt, systemctl poweroff, systemctl reboot или systemctl kexec выполняется выбранная операция, без выключения всех юнитов. Однако все процессы будут принудительно завершены, и все файловые системы будут отключены или перемонтированы только для чтения. Следовательно, это радикальный, но относительно безопасный вариант запроса немедленной перезагрузки. Если для этих операций дважды указать --force (за исключением kexec), они будут выполнены немедленно, без завершения каких-либо процессов или размонтирования каких-либо файловых систем. Предупреждение: указание --force дважды для любой из этих операций может привести к потере данных. Обратите внимание, что если дважды указать --force, выбранная операция выполняется самим systemctl, и с системным менеджером не связываются. Это означает, что команда должна выполняться даже в случае сбоя системного менеджера.

Заключение

К настоящему времени вы должны быть знакомы с некоторыми основными возможностями команды systemctl, которые позволяют вам взаимодействовать с вашим экземпляром systemd и управлять им. Утилита systemctl будет вашей основной точкой взаимодействия со слулжбами и управлением состоянием системы.

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

Смотрите также Как использовать journalctl для просмотра системных логов Linux.


Рекомендуется Вам:

12 комментариев to Как использовать Systemctl для управления службами Systemd и юнитами

  1. Андрей:

    Вы как будто в воду глядели)) Я как раз после настроек VPN (что удалось успешно благодаря вам мне он без надобности - но для образования)задумался как управляеться в Linux автозагрузках после команды на добовления в автозапуск VPN… И тут такая ценная статья…Благодарю

  2. кукумария в:

    Найденны ошибки в тексте (это не оссуждение, понятно статья большая)

    =====================================

    Тем не менее, для большинства команд управления службой вы фактически можете отросить (отбросить?) суффикс .service, поскольку systemd достаточно умён,

    ====================================

    Чтобы быть более точной (точным?), перед попыткой создать экземпляр name@.suffix шаблона юнита

    =======================================

    Мы можем сказать systemctl выводить различную информацию, используя дополнительные флаги. Например, чтобы увидеть все юинты(юниты?),

    =========================================

    В отличие от уровней запуска, несколько целей могут быть активны за один раз. Активная цель указывает, что systemd попытался запустить все юниты, привязанные к цели, и не попытался снова их оторвать(отключить?)

    ==========================================

    Удалите этот коммент если он больше не нужен.) Спасибо за статью.

     

     

    • Alexey:

      Приветствую! Спасибо за полезные замечания – всё поправил.

      П.с. Я никогда не обижаюсь (и даже не огорчаюсь) по поводу замечаний/критики – в конечном счёте, это даёт возможность улучшиться самому и улучшить результаты своей работы.

  3. Сергей:

    Здравствуйте. Подскажите пожалуйста, как установить музыку на выключение ПК с Debian9 Gnome3?  На включение всё таки сделал, а на выключение ( для настройки вводил команду - sudo systemctl enable canberra-system-shutdown.service . На эту команду выдаёт ошибку - Failed to enable unit: Unit file canberra-system-shutdown.service does not exist. Перерыл наверное весь инет. Везде для Убунты да для Минт в основном. Спасибо.

    • Alexey:

      Приветствую! Вопрос интересный (я имею в виду как запустить скрипт перед выключением компьютера, а не как включить мелодию выхода из Linux), поэтому я покопался в этой теме, но успеха не добился.

      После установки

      sudo apt install gnome-session-canberra gsound-tools

      Создаются два файла:

      • /usr/share/gnome/autostart/libcanberra-login-sound.desktop
      • /usr/share/gnome/shutdown/libcanberra-logout-sound.sh

      Я нашёл файл со звуком test.mp3, конвертировал его в test.wav (так как canberra-gtk-play с MP3 не работает):

      ffmpeg -i test.mp3 test.wav

      Проверил, что теперь программа способна воспроизводить звук:

      canberra-gtk-play -f /root/test.wav

      Файл /usr/share/gnome/shutdown/libcanberra-logout-sound.sh судя по названию должен отвечать за звук при выходе. Исходное содержимое файла:

      #!/bin/sh
      
      /usr/bin/canberra-gtk-play --id="desktop-logout" --description="GNOME Logout"

      Я добавил опцию -f после которой прописал путь до файла:

      #!/bin/sh
      
      /usr/bin/canberra-gtk-play --id="desktop-logout" --description="GNOME Logout" -f /root/test.wav

      Теперь при запуске

      /usr/share/gnome/shutdown/libcanberra-logout-sound.sh

      Можно услышать мелодию.

      Возможно, где-то в настройках GNOME можно включить автоматическое выполнение скриптов в папках /usr/share/gnome/autostart/ и /usr/share/gnome/shutdown/, но я не знаю как это сделать.

      Более того, возможно это даже работает по умолчанию, но у меня после нажатия на кнопку выключения до полного выключения проходит меньше секунды — может быть, файл просто не успевает воспроизвестись, либо GNOME закрывается раньше, чем успеет воспроизвести файл.

      В этих источниках описано, как сделать так, чтобы выполнялся файл перед выходом:

      Суть примерно такая, создаётся файл для включения пользовательской службы (это я показываю уже на примере включения звука выхода из системы):

      sudo gedit /etc/systemd/system/canberra-system-shutdown.service

      В этот файл записывается:

      [Unit]
      Description=Sound on shutdown
      DefaultDependencies=no
      Before=shutdown.target reboot.target
      
      [Service]
      Type=oneshot
      RemainAfterExit=true
      ExecStart=/bin/true
      ExecStop=/usr/share/gnome/shutdown/libcanberra-logout-sound.sh
      
      [Install]
      WantedBy=multi-user.target

      Или (вариант из другого совета):

      [Unit]
      Description=Sound on shutdown
      Before=shutdown.target
      
      [Service]
      ExecStart=/bin/true
      ExecStop=/usr/share/gnome/shutdown/libcanberra-logout-sound.sh
      RemainAfterExit=yes
      
      [Install]
      WantedBy=multi-user.target

      Как можно увидеть, я указал путь до /usr/share/gnome/shutdown/libcanberra-logout-sound.sh в качестве команды, выполняемой перед выходом.

      Включаем эту службу:

      systemctl daemon-reload
      sudo systemctl enable canberra-system-shutdown.service --now

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

      Как пишут, проблема с systemd в том, что она при запуске файла перед выключением компьютера не ждёт завершения его работы и никак не проверяет это. То есть работает по принципу «запустила файл и продолжаю выключать компьютер». Учитывая скорость выключения, не представляю, что там может успеть выполниться.

      Решение этой проблемы есть в следующей статье:

      По идее, должно работать — я сам не пробовал. Но там уже совсем костыль-костыль.

      Ещё в некоторых инструкциях советуют поместить скрипт в /usr/lib/systemd/system-shutdown/ или в /lib/systemd/system-shutdown/, но у меня это тоже не сработало. Система продолжает выключаться так, будто бы выдернули шнур из розетки.

      Ссылка на ещё один вариант:

      https://superuser.com/questions/1016827/how-do-i-run-a-script-before-everything-else-on-shutdown-with-systemd

      Может быть, что-то из этого вам пригодиться.

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

  4. bob:

    Добрый день.

    Спасибо за статью.

    Вопрос - выполнение останавливается на строке типа:

    line 1-19/19 (END)

    Что делать в этом случае? У меня получается выйти только Ctrl-C …

    А если эта команда в скрипте используется, как сделать

    sudo systemctl start приложение

      и продолжить выполнение дальше?

    В моем случае я останавливаюсь на строке line …

     

    • Alexey:

      Здравствуйте, вы случайно не systemctl status приложение вводите?

      • bob:

        Нет. Моя ошибка - я написал что появляется line …

        Как раз line не появляется

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

        …….
        Wed Mar  4 12:12:25 2020 Initialization Sequence Completed

        Выйти только Ctrl-C

        Полный текст

        Wed Mar  4 12:12:25 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
        Wed Mar  4 12:12:25 2020 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.08
        Wed Mar  4 12:12:25 2020 Diffie-Hellman initialized with 2048 bit key
        Wed Mar  4 12:12:25 2020 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
        Wed Mar  4 12:12:25 2020 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
        Wed Mar  4 12:12:25 2020 ROUTE_GATEWAY 5.101.51.1/255.255.255.0 IFACE=eth0 HWADDR=fa:16:3e:9b:50:83
        Wed Mar  4 12:12:25 2020 TUN/TAP device tun0 opened
        Wed Mar  4 12:12:25 2020 TUN/TAP TX queue length set to 100
        Wed Mar  4 12:12:25 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
        Wed Mar  4 12:12:25 2020 /sbin/ip link set dev tun0 up mtu 1500
        Wed Mar  4 12:12:25 2020 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
        Wed Mar  4 12:12:25 2020 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
        Wed Mar  4 12:12:25 2020 Could not determine IPv4/IPv6 protocol. Using AF_INET
        Wed Mar  4 12:12:25 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
        Wed Mar  4 12:12:25 2020 UDPv4 link local (bound): [AF_INET][undef]:1194
        Wed Mar  4 12:12:25 2020 UDPv4 link remote: [AF_UNSPEC]
        Wed Mar  4 12:12:25 2020 GID set to nogroup
        Wed Mar  4 12:12:25 2020 UID set to nobody
        Wed Mar  4 12:12:25 2020 MULTI: multi_init called, r=256 v=256
        Wed Mar  4 12:12:25 2020 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
        Wed Mar  4 12:12:25 2020 IFCONFIG POOL LIST
        Wed Mar  4 12:12:25 2020 Initialization Sequence Completed
        ^CWed Mar  4 12:17:00 2020 event_wait : Interrupted system call (code=4)
        Wed Mar  4 12:17:02 2020 /sbin/ip route del 10.8.0.0/24
        RTNETLINK answers: Operation not permitted
        Wed Mar  4 12:17:02 2020 ERROR: Linux route delete command failed: external program exited with error status: 2
        Wed Mar  4 12:17:02 2020 Closing TUN/TAP interface
        Wed Mar  4 12:17:02 2020 /sbin/ip addr del dev tun0 local 10.8.0.1 peer 10.8.0.2
        RTNETLINK answers: Operation not permitted
        Wed Mar  4 12:17:02 2020 Linux ip addr del failed: external program exited with error status: 2
        Wed Mar  4 12:17:02 2020 SIGINT[hard,] received, process exiting
        
        • Alexey:

          А вы уверены, что вообще используете systemctl? Может быть вы запускаете примерно так:

          openvpn /etc/openvpn/server/server.conf

          При запуске с помощью systemctl:

          sudo systemctl start openvpn-server@server.service

          максимум, что вам могут показать, это сообщение о фатальной ошибке. Если всё нормально (а, судя по логу, всё нормально — сервер или клиент успешно запущены), ничего не выводится.

          А то, что вы привили здесь, это типичный набор сообщений при запуске openvpn в командной строке в качестве службы без открепления от терминала, а не в качестве демона.

  5. Андрей:

    Все же, какая разница между

    sudo systemctl reboot

    и

    sudo reboot

    все зависит от операционной системы, как я понял, - одна выполнит сокращенный вариант, другая захочет systemctl ?

Добавить комментарий для bob Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *