systemctl rescue что делает

Systemctl-управление службами в Linux

Введение

В последнее время все больше дистрибутивов Linux переходит с других систем инициализации на systemd. Этот набор инструментов представляет быструю и гибкую модель инициализации для управления сервером с момента загрузки.

В данном руководстве мы рассмотрим наиболее важные команды, необходимые для управления сервером с поддержкой systemd. Они должны работать на версиях систем Ubuntu 15.04, Debian 8, CentOS 7, Fedora 15 и выше.

Основы управления сервисами (юнитами)

У всех команд обычной системы инициализации есть эквиваленты в systemctl. В примерах мы будем использовать службу nginx.service. Если у вас её нет, установите ее при помощи менеджера пакетов.

Для запуска службы нужно ввести:

Остановка осуществляется следующей командой:

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

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

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

Для включения автоматическооо запуска при загрузке введите:

Если нужно снова отключить службу:

Получение данных о состоянии системы

Мы можем получить от сервера с systemd огромное количество информации, чтобы узнать о состоянии системы.

Например, чтобы получить список юнитов, которые systemd считает активными, нужно выполнить следующую команду (можно даже не использовать опцию list-units, потому что она подразумевается по умолчанию):

Для вывода списка юнитов, которые systemd загружал или пытался загрузить в память, в том числе не активные в данный момент, нужно указать опцию —all:

sudo systemctl list-units —all

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

sudo systemctl list-unit-files

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

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

Файлы юнитов и зависимости

Файл юнита содержит параметры, используемые systemd для запуска и управления. Для просмотра полного содержимого файла юнита нужно выполнить команду:

Для просмотра дерева зависимостей юнита (другие юниты, активируемые systemd при запуске юнита), выполните команду:

Вывод списка зависимых юнитов, которые будут рекурсивно раскрыты. Для полного рекурсивного раскрытия всех зависимых юнитов (второй и большие уровни зависимости), воспользуйтесь опцией —all:

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

Изменение файлов юнитов

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

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

Если нужно изменить все содержимое файла, а не создавать сниппет, воспользуйтесь флагом —full:

После изменения файла юнита нужно перезагрузить сам процесс systemd для принятия изменений:

Использование целей

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

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

Для просмотра цели по умолчанию, которой systemd стремится достичь при загрузке (которая, в свою очередь, запускает все файлы юнитов, составляющие дерево зависимости этой цели), выполните команду:

multi-user.target соответствует третьему уровню запуска, проверить это можно командой

При помощи опции set-default изменить цель по умолчанию, которая будет использоваться при загрузке:

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

Изменять состояние системы для перехода между можно при помощи isolate (изолировать). Она останавливает все юниты, не привязанные к указанной цели. Убедитесь что изолируемая вами цель не останавливает важные службы. Например команда

Перезагрузит вашу систему.

Выключение и перезагрузка сервера

Для некоторых важных состояний системы есть ярлыки. Например, такой командой можно выключить сервер:

Загрузка в режиме восстановления:

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

без systemctl, но их может и не быть.

Заключение

Мы рассмотрели основы управления юнитами и службами при помощи команды systemctl, а также познакомились с концепцией целей. Для более подробной информации можно обратиться к соответствующим man-страницам

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

systemd (Русский)

systemd — набор базовых строительных кирпичиков Linux-системы. Представляет собой менеджер системы и служб, который выполняется как процесс с PID 1 и запускает остальную часть системы. systemd обеспечивает возможности агрессивной параллелизации, сокет- и D-Bus-активацию для запуска служб, запуск демонов по запросу, отслеживание процессов с помощью контрольных групп Linux, обслуживание точек (авто)монтирования, а также предлагает развитую транзакционную логику управления службами на основе зависимостей. systemd поддерживает сценарии инициализации SysV и LSB и работает как замена sysvinit. Среди прочих элементов и функций — демон журнала, утилиты управления базовой конфигурацией системы (имя хоста, дата, языковой стандарт), ведение списков вошедших в систему пользователей, запущенных контейнеров, виртуальных машин, системных учётных записей, каталогов и настроек времени выполнения, а также демоны для управления несложными сетевыми конфигурациями, синхронизации времени по сети, пересылки журналов и разрешения имён.

Contents

Основы использования systemctl

Использование юнитов

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

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

Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальном пользовательском сеансе systemd-logind и нет других активных сеансов, приведенные ниже команды сработают, даже если будут выполнены не от root. В противном случае (например, другой пользователь вошел в систему через tty) systemd автоматически запросит у вас пароль суперпользователя.

Написание файлов юнитов

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

Зависимости обычно указываются для служб, но не для целей. Так, цель network.target будет «подтянута» ещё на этапе настройки сетевых интерфейсов одной из соответствующих служб, и можно спокойно указывать эту цель как зависимость в пользовательской службе, поскольку network.target будет запущена в любом случае.

Типы служб

Службы различаются по типу запуска, и это следует учитывать при написании юнитов. Тип определяется параметром Type= в разделе [Service] :

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

Замещение файла юнита

Эта команда откроет файл /etc/systemd/system/юнит в текстовом редакторе (если файл ещё не существует, будет скопирован оригинал) и автоматически перезагрузит юнит после завершения редактирования.

Drop-in файлы

Самый простой способ — использовать команду:

Команда откроет /etc/systemd/system/юнит.d/override.conf в текстовом редакторе (файл будет создан, если его ещё нет) и автоматически перезапустит юнит после завершения редактирования.

Откат изменений

Примеры

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

Другой пример: для замены ExecStart в юните (кроме типа oneshot ) создайте следующий файл:

Обратите внимание, что ExecStart необходимо очистить перед присвоением нового значения [1]. Это относится ко всем параметрам, которые позволяют прописать несколько значений, вроде OnCalendar в таймерах.

Пример настройки автоматического перезапуска службы:

Получение информации о текущих целях

В systemd для этого предназначена следующая команда (заменяющая runlevel ):

Создание пользовательской цели

Соответствие уровней SysV целям systemd

Изменение текущей цели

В systemd цели доступны посредством целевых юнитов. Вы можете переключать их такой командой:

Изменение цели загрузки по умолчанию

Узнать текущую цель можно так:

Альтернативный способ — добавить один из следующих параметров ядра в загрузчик:

Порядок выбора цели по умолчанию

systemd выбирает default.target в следующем порядке :

Компоненты systemd

Некоторые (не все) составные части systemd:

systemd.mount — монтирование

Примером этих опций может быть т.н. автомонтирование (здесь имеется в виду не автоматическое монтирование во время загрузки, а монтирование при появлении запроса от устройства). Подробнее смотрите fstab#Автоматическое монтирование с systemd.

Автомонтирование GPT-раздела

На UEFI-системах systemd-gpt-auto-generator(8) автоматически монтирует GPT-разделы в соответствии с Discoverable Partitions Specification, поэтому их можно не указывать в файле fstab.

Для автомонтирования раздела /var его PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой:

systemd-sysvcompat

systemd-tmpfiles — временные файлы

Советы и рекомендации

Программы настройки с графическим интерфейсом

Запуск сервисов после подключения к сети

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

Также должна быть включена служба ожидания сети того приложения, которое управляет сетью; только тогда network-online.target будет соответствовать состоянию сети.

Подробнее можно почитать в systemd wiki: Running services after the network is up.

Если служба отправляет DNS-запросы, она должна запускаться также после nss-lookup.target :

Чтобы цель nss-lookup.target работала как положено, должна быть служба, которая запускает её параметром Wants=nss-lookup.target и размещает себя перед ней ( Before=nss-lookup.target ). Обычно это выполняет локальный DNS-распознаватель.

Включение установленных юнитов по умолчанию

This article or section needs expansion.

Песочница для приложений

Рекомендации по созданию песочницы с помощью systemd:

Уведомление о неработающих службах

Создайте drop-in верхнего уровня:

Это добавит строку OnFailure=failure-notification@%n в файл каждой службы. Если какой-то_юнит завершится с ошибкой, запустится экземпляр службы failure-notification@какой-то_юнит для создания уведомления (или любой другой задачи, которая была назначена).

Создайте юнит-шаблон failure-notification@ :

Решение проблем

Неудачно запущенные службы

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

Чтобы определить причину, по которой служба не запустилась, необходимо изучить записи её логов. Подробнее см. systemd/Журнал#Фильтрация вывода.

Диагностика загрузки системы

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

Диагностика службы

Добавьте drop-in файл для службы:

Или, как вариант, пропишите переменную окружения вручную:

Выключение/перезагрузка происходят ужасно долго

Если процесс выключения занимает очень долгое время (или выглядит зависшим), то, вероятно, виновата служба, которая не может завершить свою работу. Systemd ожидает некоторое время, пока каждая служба прекратит работу самостоятельно, и только потом пробует завершить её принудительно. Если вы столкнулись с такой проблемой, обратитесь к Shutdown completes eventually в systemd-вики.

По-видимому, процессы с кратким сроком жизни не оставляют записей в логах

Время загрузки системы увеличивается с течением времени

После использования systemd-analyze некоторые пользователи заметили, что время загрузки системы значительно увеличилось. После использования systemd-analyze blame NetworkManager запускался необычно долго.

systemd-tmpfiles-setup.service не запускается во время загрузки

Начиная с версии Systemd 219, /usr/lib/tmpfiles.d/systemd.conf определяет ACL-атрибуты для каталогов в /var/log/journal и, следовательно, требует включённой поддержки ACL для той файловой системы, в которой находится журнал.

Отключение emergency mode на удалённой машине

Вам может понадобиться отключить emergency mode на удалённой машине, например на виртуальных машинах Azure или Google Cloud. Это связано с тем, что в случае ухода системы в emergency mode она отключится от сети и лишит вас возможности подключения к ней.

Источник

Systemd для самых маленьких. Часть I. Знакомство

Внимание! Данный пост не для холивара в стиле «нужен/не нужен», «не unix-way», «когда Поттеринг запилит свою ось?» и т.п. Пост содержит исключительно информацию по работе с systemd.

Привет вам, красноглазые братья и сёстры!

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

Глава 1. В плену shell-скриптов.

Уровень по умолчанию задавался в файле /etc/inittab, а поменять на лету можно было при помощи команды init номер_уровня. Например,

для выключения машины. Все скрипты запускались последовательно (это важно!). Позднее Ubuntu запилила свою СИ с блэкджеком и событийной моделью под именем upstart. Но о ней мы говорить не будем, т.к. даже сама Ubuntu отказалась от неё в пользу systemd.

Ладно, переборщил я со вступлением. Держите скрин и переходим к «виновнику торжества».

Глава 2. Systemd и все-все-все.

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

На сегодняшний день sd применяется в Debian (c 8-й версии), Ubuntu (с 15.04 версии), Fedora (c 15 версии), openSUSE (с 12.1), ArchLinux (12.11) и т.д.

Расположены директории в порядке повышения приоритета.

Юниты можно запускать и останавливать.

Как я сказал, юниты делятся на типы (с соответ. расширениями файлов):

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

Секция [Unit] содержит основную информацию о юните, а также о зависимостях порядка и зависимостях требования. Итак, параметры:

Зависимости порядка и зависимости требования НЕ связаны между собой. В данном примере, сказано, что sshd.service должен запустится после network.target. Но это никоим образом не значит, что network.target будет запущен! Однако если он запущен (допустим, его запустил другой сервис), то стартуем после него, если не запущен, то и фиг с ним.

Но вернемся к sshd. Секция [Service] описывает тип юнита service. В других типах своё. Например, в юнитах типа socket есть секция [Socket]

Секцию [Install] пока просто запомним, ниже расскажу, где она используется.

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

Глава 3. Одна за всех.

Прежде чем начинать описывать команды, хотелось бы пару слов сказать про юнит типа target. Как кратко было сказано выше, этот тип юнита не делает ничего, просто объединяя другие юниты. Технически этот юнит представляет из себя директорию с симлинкми на другие юниты.

Target-ы являются аналогами уровней в SysVinit. Т.е., допустим, target с именем multi-user является аналогом 2/3 уровня и содержит симлинки на юниты, которые будут запущены при выполнении этого target-а. По умолчанию выполняется target с именем default.target, который обычно является псевдонимом для graphical.target (аналог 5 уровня).

Итак команды. Основная команда, это

systemctl, запущенная без параметров, является псевдонимом для более полной команды systemctl list-units. Она покажет список юнитов, а также их состояния. С помощью ключа -t можно задать тип юнитов, а —all выведет все юниты, в том числе и неактивные. Например:

покажет общее состояние системы и перечислит юниты, которым соответствуют какие-либо запущенные процессы. В то же самое время, эта команда, дополненное именем юнита покажет более подробную информацию о юните. Например:

покажет содержимое юнита.

systemctl stop unit_name

Примечание: по умолчанию принимается тип service. Таки образом команды

systemctl start sshd.service

systemctl start sshd

Тут все просто и понятно. Единственное, что стоит уточнить, так это то, что эти манипуляции применяются только в текущей сессии. При рестарте все вернется на круги своя.

А что тогда делать, если мы хотим добавить юнит в автозагрузку? Опять systemctl

systemctl disable unit_name

Еще помните секцию Install, которую я сказал, что опишу позднее? Если не помните, то вот она:

Ну так вот, эта секция используется командами systemctl enable/disable для добавления симлинка в нужный target (создания иск. зависимости). Конкретно в этом случае, при выполнении команды

в папке multi-user.target будет создан симлинк на sshd.service и при выполнении данного target-a sshd будет запущен.

Кстати, проверить наличие юнита в автозагрузке можно командой

Она вернет enabled/disabled. Логично же)

просто удаляет симлинк.

Само собой, что можно просто запустить нужный target. Например:

Но гораздо проще использовать сокращенный аналог, убрав start и target, т.е.:

Также у нас имеется «лицензия на убийство»

Хотите перезапустить все юниты и перестроить дерево зависимостей? Не проблема

Источник

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

Published on December 1, 2020

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При этом вы получите статус службы, иерархию контрольных групп и первые несколько строк журнала.

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

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

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

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

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

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

Список текущих модулей

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

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

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

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

Список все файлов модулей

Управление модулями

Отображение файла модуля

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

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

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

Проверка свойств модуля

Маскировка и снятие маскировки модулей

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

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

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

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

Редактирование файлов модулей

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

Команда edit по умолчанию откроет фрагмент файла модуля для интересующего модуля:

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

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

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

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

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

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

Вы можете получить список имеющихся целей в вашей системе, введя:

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

Изолирование целей

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

Если вы удовлетворены модулями, которые будут сохранены в активном состоянии, можно изолировать цель, введя:

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

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

Например, чтобы перевести систему в режим спасения (один пользователь), можно использовать команду rescue вместо isolate rescue.target :

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

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

Для инициализации полного отключения можно использовать команду poweroff :

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

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

Заключение

Источник