Управление службами Systemd. Часть 1 из 3
Управление сервисами
Основная цель Systemd — инициализировать компоненты, которые должны запускаться после загрузки ядра Linux. Systemd (и команда systemctl ) также используется для управления сервисами и демонами сервера.
Запуск и остановка сервиса
Для запуска сервиса предназначена команда start :
Чтобы остановить сервис, достаточно ввести команду stop :
Перезапуск и перезагрузка
Для запуска сервиса systemd предназначена команда restart :
Если приложение может перезагрузить свои конфигурационные файлы (без перезапуска), можно использовать команду reload :
Включение и отключение сервисов
Приведенные выше команды необходимы при работе с сервисом в текущей сессии. Чтобы добавить сервис в автозагрузку Systemd, его нужно включить. Для этого существует команда enable :
Это создаст символическую ссылку на файл сервиса (этот файл обычно расположен в /lib/systemd/system или /etc/systemd/system ) в специальном каталоге, где Systemd ищет файлы для автозапуска (обычно /etc/systemd/system/something.target.want ).
Посмотрим содержимое каталога /etc/systemd/system и отфильтруем только директории *.wants :
Заглянем в директорию bluetooth.target.wants :
Заглянем в директорию multi-user.target.wants :
Чтобы убрать сервис из автозагрузки, нужно ввести:
Это удалит символическую ссылку, после этого сервис перестанет запускаться автоматически.
Проверка состояния сервиса
Для проверки состояния сервиса предназначена команда status :
Эта команда выведет состояние сервиса, иерархию групп и первые несколько строк лога. Например, при проверке состояния сервера Nginx, можно увидеть такой вывод:
Это предоставляет обзор текущего состояния приложения, уведомляет о любых проблемах и любых действиях, которые могут потребоваться в дальнейшем. Существуют также методы проверки конкретных состояний.
Последняя команда позволяет определить, находится ли юнит в состоянии сбоя. Это указывает на то, что возникла проблема с запуском рассматриваемого юнита.
Обзор состояния системы
Ранее мы рассмотрели команды, необходимые для управления отдельными сервисами, но они не очень полезны для изучения текущего состояния системы. Существует несколько команд systemctl, которые предоставляют эту информацию.
Просмотр списка текущих юнитов
Для просмотра списка текущих юнитов предназначена команда list-units :
В выводе есть такие столбцы:
Чтобы увидеть все юниты, которые загрузила (или попыталась загрузить) система Systemd, независимо от того, активны ли они в данный момент:
Еще один популярный фильтр — это type :
Флаги можно комбинировать:
Список юнит-файлов
Как в Linux пользоваться командой systemctl
Вместе с подсистемой systemd появилась команда systemctl. Она позволяет управлять основными процессами Linux. Ниже представлена небольшая инструкция в виде шпаргалки наиболее используемых команд.
Общий синтаксис
Без параметров, systemctl показывает список запущенных служб, точек монтирования, устройств и других юнитов.
Примерный вывод команды:
1) название юнита;
2) тип юнита (например, service: служба или демон, mount: точка монтирования, device: устройства);
3) состояние юнита (загружен или нет);
4) обобщенный статус юнита (active: выполняется, inactive: не был запущен, maintenance: требуется внимание администратора);
5) текущий статус (запущен или нет);
6) описание.
Шпаргалка по часто используемым командам systemctl
1. Посмотреть статус службы:
systemctl status network
* покажет статус службы на примере сети network
2. Запустить сервис:
systemctl start mysql
* запустит сервис баз данных на примере mysql
3. Остановить службу:
systemctl stop ntpd
* остановит сервис времени ntpd
4. Перезапустить службу:
systemctl restart nginx
* перезапустит веб-сервер nginx
5. Включить автозапуск службы:
systemctl enable apache
* разрешит автозапуск веб-сервера apache
6. Отключить автозапуск службы:
systemctl disable firewalld
* запретит автозапуск брандмауэра firewalld
7. Выполнить команду на удаленной системе:
* остановит cron на компьютере с IP-адресом 192.168.0.15, подключившись под учетной записью root.
8. Перезагрузить сервер:
* перезагрузит локальный сервер.
9. Проверка работы сервиса.
Выполняется с помощью опции is-active:
systemctl is-active docker
* в данном примере мы проверим работу службы docker.
а) Если сервис запущен, мы увидим:
в) Если такого сервиса нет в системе:
Если сервис не работает или его нет в системе, команда вернет код ошибки, таким образом конструкция:
systemctl is-active docker && docker run hello-world
. приведет к выполнению команды docker run hello-world только в том случае, если сервис docker работает.
Автозапуск
Подсистему systemd также можно использовать для автозапуска сервисов или скриптов. Для этого в каталоге /usr/lib/systemd/system создаем юнит (файл) с расширением .service. Подробнее разберем на примере сервиса bind:
Содержимое может быть следующего содержания:
[Unit]
Description=Berkeley Internet Name Domain (DNS)
Wants=nss-lookup.target
Wants=named-setup-rndc.service
Before=nss-lookup.target
After=network.target
After=named-setup-rndc.service
* как правило, файл разделен на 3 части:
Подробнее можно почитать о структуре и возможных опциях на странице https://linux-notes.org/pishem-systemd-unit-fajl/
После внесения изменений и сохранения файла, необходимо перечитать изменения командой:
Теперь можно разрешить автозапуск:
systemctl enable named
Редактирование сервисов
Если мы хотим внести изменения в юнит-файл сервиса, который был установлен с последним, необходимо использовать drop-in файл или файл переопределения настроек. В противном случае, после обновления программы наши изменения могут быть удалены.
И так, мы для примера взяли юнит для bind. Чтобы создать для него drop-in файл, вводим:
systemctl edit named
И вносим, например, такие изменения:
* будет создан файл /etc/systemd/system/named.service.d/override.conf, который будет переопределять настройки основного юнит-файла. В данном примере, мы указываем на необходимость перезапуска сервиса при сбое.
Чтобы убедиться в использовании Drop-In файла смотрим статус сервиса:
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 автоматически запросит у вас пароль суперпользователя.
| Действие | Команда |
|---|---|
| Завершить работу и перезагрузить систему | $ systemctl reboot |
| Завершить работу и выключить компьютер | $ systemctl poweroff |
| Перевести систему в ждущий режим | $ systemctl suspend |
| Перевести систему в спящий режим | $ systemctl hibernate |
| Перевести систему в режим гибридного сна (suspend-to-both) | $ systemctl hybrid-sleep |
Написание файлов юнитов
Обработка зависимостей
Зависимости обычно указываются для служб, но не для целей. Так, цель 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
| Уровнень запуска SysV | Цель systemd | Примечания |
|---|---|---|
| 0 | runlevel0.target, poweroff.target | Выключение системы |
| 1, s, single | runlevel1.target, rescue.target | Однопользовательский уровень запуска |
| 2, 4 | runlevel2.target, runlevel4.target, multi-user.target | Уровни запуска, определенные пользователем/специфичные для узла. По умолчанию соответствует уровню запуска 3 |
| 3 | runlevel3.target, multi-user.target | Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть |
| 5 | runlevel5.target, graphical.target | Многопользовательский режим с графикой. Обычно эквивалентен запуску всех служб на уровне 3 и графического менеджера входа в систему |
| 6 | runlevel6.target, reboot.target | Перезагрузка |
| emergency | emergency.target | Аварийная оболочка |
Изменение текущей цели
В 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 она отключится от сети и лишит вас возможности подключения к ней.
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Как использовать Systemctl для управления службами Systemd и юнитами
Оглавление
Введение
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, поскольку выполняемая команда повлияет на состояние операционной системы:
Как мы уже упоминали выше, systemd знает, что нужно искать файлы *.service для команд управления службами, поэтому эту команду можно без проблем ввести следующим образом:
Хотя вы можете использовать вышеуказанный формат для обычного администрирования, для ясности в остальной части команд мы будем использовать суффикс .service, чтобы быть явным в отношении цели, над которой мы работаем.
Чтобы остановить текущую службу, используется команда stop:
Перезапуск и перезагрузка
Чтобы перезапустить запущенную службу, вы можете использовать команду restart:
Если рассматриваемое приложение может перезагрузить свои файлы конфигурации (без перезапуска), вы можете выполнить команду reload, чтобы инициировать этот процесс:
Если вы не знаете, есть ли у службы функциональность для перезагрузки конфигурации, вы можете выполнить команду reload-or-restart. Она перезагрузит конфигурацию, если приложение поддерживает это. В противном случае она перезапустит службу, чтобы была подхвачена новая конфигурация:
Включение и отключение служб
Вышеупомянутые команды полезны для запуска или остановки команд во время текущего сеанса. Чтобы система systemd автоматически запускала службы при загрузке компьютера, вы должны включить их.
Чтобы запустить службу при загрузке, используйте команду enable:
Это создаст символическую ссылку из копии файла системной службы (обычно в /lib/systemd/system или /etc/systemd/system) в место на диске, где systemd ищет файлы автозапуска (обычно /etc/systemd/system/некая_цель.target.wants). Мы перейдем к тому, что такое цель (target), позже в этом руководстве).
Чтобы отключить автоматический запуск службы, вы можете набрать:
Это приведет к удалению символической ссылки, указывающей, что служба должна запускаться автоматически.
Имейте в виду, что включение службы не запускает ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, вам придется выпустить команды start и enable. Чтобы одновременно добавить службу в автозагрузку и запустить её, используйте ключ —now:
Приведённая команда добавить веб-сервер Apache в автозагрузку и немедленно запустит его.
Переключатель —now работает с командами enable, disable и mask, соответственно для немедленного запуска, остановки или маскировки юнита, без ожидания следующей загрузки.
Символ @ («собака») в именах служб
Некоторые имена юнитов содержат символ @ (т.е. name@string.service): это означает, что они являются экземплярами юнита-шаблона, чьё действительное имя не содержит часть, которая в условном примере обозначена как string (т.е. name@.service). string называется идентификатором экземпляра и аналогична аргументу, который передается юниту-шаблону при вызове с помощью команды systemctl: в файле юнита он будет заменять спецификатор %i.
Для большей точности работы, перед попыткой создать экземпляр name@.suffix юнита-шаблона, systemd действительно ищет юнит с точным именем файла name@string.suffix, даже не смотря на то, что такие «конфликты» довольно редки, так как большинство файлов юнитов, содержащих знак @, подразумевают использование шаблонов. Кроме того, если юнит-шаблон вызывается без идентификатора экземпляра, ничего не получится, так как спецификатор %i не может быть подставлен.
К примеру, в файле юнита OpenVPN:
В этой строке виден спецификатор %i, при его замене получится имя файла логов и файла конфигурации.
Используя различные значения string, можно добиться настройки автозапуска OpenVPN с различными конфигурационными файлами. Например:
Этой командой служба OpenVPN будет добавлена в автозапуск, при этом она будет запускаться с конфигурационным файлом /etc/openvpn/server/port_tcp_443.conf. Используя такой подход, можно настроить автозапуск одной и той же службы с разными конфигурациями. Например, OpenVPN на разных портах.
Многие службы поддерживают модель шаблоны-экземпляры. К примеру, Apache2:
Эта команда приведёт к тому, что значение переменной окружения APACHE_CONFDIR будет установлено на /etc/apache2-test.
Проверка состояния служб
Чтобы проверить статус службы в вашей системе, вы можете использовать команду status:
Это выведет состояние службы, иерархию cgroup и первые несколько строк журнала.
Например, при проверке состояния веб-сервера Apache вы можете увидеть вывод следующим образом:
Это даёт вам хороший обзор текущего состояния приложения, уведомляет вас о любых проблемах и любых действиях, которые могут потребоваться.
Существуют также методы проверки конкретных состояний. Например, чтобы проверить, активен ли данный элемент (работает), вы можете использовать команду is-active:
Это вернет текущее состояние юнита, которое обычно является active или inactive. Код выхода будет «0», если он активен, делая результат проще для парсинга программами и скриптами.
Чтобы узнать, включён ли юнит для автозапуска, вы можете использовать команду is-enabled:
Будет выведено enabled или disabled, и снова код выхода будет установлен на «0» или «1» в зависимости от ответа на вопрос команды.
Третья проверка заключается в том, находится ли устройство в состоянии сбоя. Это указывает на то, что возникла проблема с запуском рассматриваемого юнита:
Это вернёт active, если он работает правильно или failed, если произошла ошибка. Если устройство было намеренно остановлено, то может быть возвращено unknown или inactive. Состояние выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на любой другой статус.
Следующая команда покажет сразу все завершившиеся неудачей юниты:
Обзор состояния системы
Команды до сих пор были полезны для управления отдельными службами, но они не очень полезны для изучения текущего состояния системы. Существует несколько команд systemctl, которые предоставляют эту информацию.
Список текущих юнитов
Чтобы просмотреть список всех активных юнитов, о которых система знает, мы можем использовать команду list-units:
Это покажет вам список всех юнитов, которые в настоящее время systemd имеет в статусе active. Результат будет выглядеть примерно так:
Вывод имеет следующие столбцы:
Поскольку команда list-units показывает по умолчанию только активные юниты, все вышеперечисленные записи будут отображаться как «loaded» в столбце LOAD и «active» в столбце ACTIVE. Такое отображение фактически является поведением systemctl по умолчанию при вызове без дополнительных команд, поэтому вы увидите то же самое, если вы вызываете systemctl без аргументов:
Мы можем сказать systemctl выводить различную информацию, используя дополнительные флаги. Например, чтобы увидеть все юниты, которые systemd загрузила (или попыталась загрузить), независимо от того, активны ли они в данный момент, вы можете использовать флаг —all, например:
Это покажет любой юнит, который система загрузила или попыталась загрузить, независимо от текущего состояния в системе. После запуска некоторые юниты становятся неактивными, а некоторые юниты, которые пыталась загрузить systemd, не могли быть найдены на диске.
Вы можете использовать другие флаги для фильтрации этих результатов. Например, мы можем использовать —state= флаг для указания состояний LOAD, ACTIVE или SUB, которые мы хотим видеть. Также нужно указывать флаг —all, чтобы systemctl позволяла отображать неактивные юниты:
Другим распространенным фильтром является фильтр —type=. Мы можем сказать systemctl отображать только те юниты, которые нас интересуют. Например, чтобы видеть только активные юниты служб, мы можем использовать:
Предыдущая команда покажет только активные службы, для вывода информации о всех службах добавьте ключ —all:
Вы можете явно указать статус модулей, список которых хотите получить. Для этого используйте команду:
В качестве СТАТУСа могут быть значения:
Например, вывод служб, которые завершили свою работу:
Вывод служб, которые запущены в данный момент:
Вывод списка всех файлов юнитов
Команда list-units отображает только юниты, которые systemd попыталась разобрать и загрузить в память. Поскольку systemd будет читать только юниты, которые, по её мнению, нужны, список не обязательно будет включать все доступные юниты в системе. Чтобы просмотреть каждый доступный файл юнита в путях systemd, включая те, которые systemd не пыталась загрузить, вместо этого вы можете использовать команду list-unit-files:
Юниты являются представлением ресурсов, о которых знает systemd. Поскольку systemd не обязательно читает все определения юнитов в этом представлении, она показывает только информацию о самих файлах. Вывод состоит из двух столбцов: файла юнита и состояние.
Если вы хотите посмотреть только юниты, добавленные в автозагрузку, то используйте следующую конструкцию:
Этими состояниями обычно являются «enabled», «disabled», «static» или «masked». В этом контексте static означает, что в файле unit не содержится раздел «install», который используется для включения устройства. Таким образом, эти блоки не могут быть включены. Обычно это означает, что устройство выполняет одноразовое действие или используется только как зависимость другого устройства и не должно запускаться само по себе.
Чуть ниже мы рассмотрим, что означает «masked».
Управление юнитами
До сих пор мы работали со службами и отображали информацию о юнитах и единичных файлах, о которых знает systemd. Однако мы можем узнать более конкретную информацию о юнитах, используя некоторые дополнительные команды.
Показ файла юнита
Чтобы отобразить файл юнита, который systemd загрузила в свою систему, вы можете использовать команду cat (она была добавлена в версии systemd 209). Например, чтобы увидеть файл юнита веб-сервера Apache, мы можем ввести:
Будет показано что-то вроде:
Будет выведен файл юнита как он известен текущему работающему процессу systemd. Это может быть важно, если вы недавно модифицировали файлы юнитов, или если вы переопределяете некоторые параметры в фрагменте файла юнита (мы расскажем об этом позже).
Отображение зависимостей
Чтобы увидеть дерево зависимостей юнита, вы можете использовать команду list-dependencies:
Это отобразит иерархию, сопоставляющую зависимости, с которыми необходимо иметь дело, чтобы запустить рассматриваемый юнит. Зависимости в этом контексте включают те юниты, которые требуются или ищутся юнитами, расположенными над ним.
Рекурсивные зависимости отображаются только для юнитов .target, которые указывают состояния системы. Чтобы рекурсивно перечислить все зависимости, включите флаг —all.
Чтобы показать обратные зависимости (юниты, зависящие от указанного юнита), вы можете добавить в команду флаг —reverse. Другими полезными флагами являются флаги —before и —after, которые могут использоваться для отображения юнитов, которые зависят от указанного устройства, начиная с до и после себя, соответственно.
Проверка свойств юнита
Чтобы увидеть низкоуровневые свойства юнита, вы можете использовать команду show. Она отобразит список свойств, заданных для указанного юнита, используя формат ключ=значение:
Если вы хотите отобразить одно свойство, вы можете передать с флагом -p имя свойства. Например, чтобы увидеть конфликты, которые имеет юнит ssh.socket, вы можете ввести:
Применение и снятие маски юнитов
В разделе управления службами мы рассмотрели, как остановить или отключить службу, но systemd также имеет возможность пометить устройство как полностью неспособное к запуску, автоматически или вручную, связав его с /dev/null. Это называется маскировкой юнитов и возможно с помощью команды mask:
Это предотвратит запуск службы Nginx, автоматически или вручную, до тех пор, пока она замаскирована.
Если вы проверите list-unit-files, вы увидите, что служба теперь отображается как masked (замаскированная):
Если вы попытаетесь запустить службу, вы увидите следующее сообщение:
Чтобы снять маску с юнита, сделав его доступным для использования снова, просто используйте команду unmask:
Это вернет юнит в прежнее состояние, позволяя ему запускаться или включаться.
Редактирование файлов юнитов
Хотя в этом руководстве мы не будет затрагивать вопрос формата файлов юнитов, знайте, что systemctl предоставляет встроенные механизмы для редактирования и изменения файлов юнитов, если вам нужно внести коррективы. Эта функциональность была добавлена в systemd версии 218.
Команда edit по умолчанию откроет фрагмент файла юнита для данного элемента:
Это будет пустой файл, который может использоваться для переназначения или добавления директив к определению юнита. Будет создана директория внутри директории /etc/systemd/system, которая содержит имя юнита с добавленным .d. Например, для службы ssh.socket будет создана директория /etc/systemd/system/ssh.socket.d/.
Внутри этой директории будет создан сниппет (фрагмент) с именем override.conf. Когда загружается юнит, systemd будет в памяти объединять фрагмент переопределения с полным файлом юнита. Директивы фрагмента будут иметь приоритет над теми, что указаны в исходном файле юнита.
Если вы хотите отредактировать полный файл юнита вместо создания фрагмента, вы можете передать флаг —full:
Это загрузит текущий файл юнита в редактор, где его можно будет изменить. При выходе из редактора, измененный файл будет записан в /etc/systemd/system, он будет иметь приоритет над системным определением юнита (который обычно находится где-то в /lib/systemd/system).
Для изменения файла откроется редактор joe или vim (в зависимости того, который выбран по умолчанию для вашего дистрибутива). Поэтому рекомендуется ознакомиться с Основами использования Joe’s Own Editor.
Чтобы удалить все сделанные вами дополнения, удалите каталог конфигурации .d или измененный служебный файл из /etc/systemd/system. Например, чтобы удалить сниппет, мы можем ввести:
Для удаления полного модифицированного файла юнита, можно было бы напечатать:
После удаления файла или каталога вы должны перезагрузить процесс systemd, чтобы он больше не пытался ссылаться на эти файлы и возвращался обратно к использованию системных копий. Вы можете сделать это, набрав:
Настройка состояния системы (уровень запуска) с помощью целей
Целями (targets) являются специальные файлы юнитов, которые описывают состояние системы или точку синхронизации. Как и другие юниты, файлы, которые определяют цели, могут быть идентифицированы по их суффиксу, которым в этом случае является .target. Цели сами по себе много не делают, но вместо этого используются для группировки других единиц.
Это можно использовать, чтобы привести систему в определенные состояния, так же как и другие системы инициализации используют уровни запуска. Они используются в качестве справочного материала, когда доступны определенные функции, позволяя вам указать желаемое состояние вместо отдельных юнитов, необходимых для создания этого состояния.
Например, есть swap.target, который используется для указания того, что swap готов к использованию. Юниты, которые являются частью этого процесса, могут синхронизироваться с этой целью, указывая в своей конфигурации, что они WantedBy= или RequiredBy= цель swap.target. Юниты, для которых требуется файл подкачки, могут указывать это условие, используя спецификации Wants=, Requires= и After=, чтобы указать характер их отношений.
Получение и установка дефолтной цели
Процесс systemd имеет цель по умолчанию, которую он использует при загрузке системы. Удовлетворение каскада зависимостей от этой единственной цели приведет систему в желаемое состояние. Чтобы найти цель по умолчанию для вашей системы, введите:
Если вы хотите установить другую цель по умолчанию, вы можете использовать set-default. Например, если у вас установлен графический рабочий стол, и вы хотите, чтобы система загрузилась по умолчанию в графическое окружение, вы можете соответствующим образом изменить цель по умолчанию:
Список доступных целей
Вы можете получить список доступных целей в своей системе, введя:
В отличие от уровней запуска, несколько целей могут быть активны за один раз. Активная цель указывает, что systemd попытался запустить все юниты, привязанные к цели, и не попытался снова их отключить (teardown). Чтобы увидеть все активные цели, введите:
Изоляция целей
Можно запустить все юниты, связанные с целью, и остановить все юниты, которые не являются частью дерева зависимостей. Команда, которая нам нужна для этого, называется isolate. Это похоже на изменение уровня запуска в других системах инициализации.
Например, если вы работаете в графической среде с активным graphical.target, вы можете отключить графическую систему и перевести систему в состояние многопользовательской командной строки, изолировав multi-user.target. Поскольку graphical.target зависит от multi-user.target, но не наоборот, все графические блоки будут остановлены.
Вы можете взглянуть на зависимости цели, которую вы изолируете, прежде чем выполнять эту процедуру, чтобы убедиться, что вы не останавливаете жизненно важные службы:
Если вас устраивают юниты, которые будут сохранены в живых, вы можете изолировать цель, набрав:
Использование ярлыков для важных событий
Имеются цели, определенные для важных событий, таких как выключение или перезагрузка. Тем не менее, systemctl также имеет несколько ярлыков, которые добавляют немного дополнительной функциональности.
Например, чтобы вывести систему в режим спасения (однопользовательский), вы можете просто использовать команду rescue вместо изолирования rescue.target:
Это обеспечит дополнительную функциональность оповещения всех зарегистрированных пользователей о событии.
Чтобы остановить систему, вы можете использовать команду halt:
Чтобы начать полное завершение работы, вы можете использовать команду poweroff:
Перезапуск можно запустить с помощью команды reboot:
Все эти оповещения регистрируются пользователями, для которых происходит это событие; а то, что просто запускает или изолирует цель – нет. Обратите внимание, что большинство машин свяжут более короткие, более обычные команды для этих операций, чтобы они работали правильно с systemd.
Например, чтобы перезагрузить систему, вы обычно можете ввести:
Заключение
К настоящему времени вы должны быть знакомы с некоторыми основными возможностями команды systemctl, которые позволяют вам взаимодействовать с вашим экземпляром systemd и управлять им. Утилита systemctl будет вашей основной точкой взаимодействия со слулжбами и управлением состоянием системы.
Хотя systemctl работает в основном с процессом ядра systemd, в системе systemd есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналом и пользовательские сеансы, обрабатываются отдельными демонами и утилитами управления (journald/journalctl и logind/loginctl соответственно). Найдите время, чтобы ознакомиться с этими другими инструментами и демонами, это сделает управление более простой задачей.
