Что такое systemd linux

Обновлено: 03.07.2024

Изучите основные принципы системы инициализации systemd: как ее настроить и использовать для администрирования системы.

Понимание systemd

Systemd — это системный и сервисный менеджер для Linux, совместимый со сценариями инициализации SysV и LSB. Systemd обеспечивает:

Агрессивные возможности параллелизации

Использует активацию сокета и D-Bus для запуска служб

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

Поддерживает моментальные снимки и восстановление состояния системы

Поддерживает точки монтирования и автомонтирования

Реализует сложную логику управления сервисом на основе транзакционных зависимостей.

Команда systemctl — это основной инструмент для управления systemd. Он объединяет функциональные возможности службы SysVinit и команд chkconfig в единый инструмент, который можно использовать для постоянного включения и отключения служб или только для текущего сеанса.

Systemd управляет так называемыми юнитами, представляющими системные ресурсы и службы. В следующем списке показаны типы объектов, которыми может управлять systemd:

Служба в системе, включая инструкции по запуску, перезапуску и остановке службы.

Сетевой сокет, связанный со службой.

Устройство, специально управляемое с помощью systemd.

Точка монтирования, управляемая с помощью systemd.

Точка монтирования автоматически монтируется при загрузке.

Обмен местами в системе.

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

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

Таймер для планирования активации другого устройства.

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

Ограничение ресурсов через узлы группы управления Linux (cgroups).

Информация от интерфейсов шины systemd. Обычно используется для управления внешними системными процессами.

Запуск, остановка и запрос служб systemd

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

Предпосылки

Вы вошли в систему как пользователь с правами администратора.

Процедура

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

Немедленно активируйте услугу:

Немедленно отключить службу:

Перезапустить службу:

Показать статус службы, включая то, запущена она или нет:

Включить запуск службы при загрузке:

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

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

Проверьте, включена ли служба:

Дополнительная информация

Чтобы узнать больше, запустите man systemctl.

Изменение существующих служб systemd

Предпосылки

Вы вошли в систему как пользователь с правами администратора.

Процедура

Службы

Systemd можно изменить с помощью команды редактирования systemctl.

Добавьте свою пользовательскую конфигурацию. Например:

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

Сохраните файл. Systemd автоматически загружает новую конфигурацию службы.

Дополнительная информация

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

Создание новых сервисов systemd

В этом примере показано, как создать файл модуля для пользовательской службы. Файлы пользовательских модулей находятся в /etc/systemd/system/ и имеют расширение .service. Например, пользовательская служба foo использует файл модуля /etc/systemd/system/foo.service.

Предпосылки

Вы вошли в систему как пользователь с правами администратора.

Процедура

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

Создайте и отредактируйте новый файл конфигурации:

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

В разделе [Unit] представлена основная информация об услуге. Служба foo использует следующие параметры:

Строка, описывающая единицу измерения. Systemd отображает это описание рядом с именем объекта в пользовательском интерфейсе.

Определяет связь со второй единицей. Если вы активируете юнит, systemd активирует его только после второго. Например, для службы foo может потребоваться подключение к сети, что означает, что службы foo указывают network.target как условие After=.

Результирующий раздел [Unit] выглядит следующим образом:

В разделе [Сервис] приведены инструкции по управлению сервисом. Служба foo использует следующие параметры:

Определяет тип службы systemd. В этом примере служба foo представляет собой простую службу, которая запускает службу без особого внимания.

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

Результирующий раздел [Сервис] выглядит следующим образом:

В разделе [Установка] приведены инструкции о том, как systemd устанавливает службу. Служба foo использует следующие параметры:

Определяет, какая служба запускает пользовательскую службу, если она включена с помощью systemctl enable . Это в основном используется для запуска пользовательской службы при загрузке. В этом примере foo.service использует multi-user.target , который запускает foo.service, когда systemd загружает multi-user.target при загрузке.

Полный файл foo.service содержит следующее содержимое:

Чтобы сообщить systemd о новом сервисе, перезагрузите его служебные файлы

Запустите пользовательский сервис foo:

Проверьте состояние службы, чтобы убедиться, что она работает:

Дополнительная информация

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

Преобразование служб SysVinit в systemd

Старые версии Fedora используют сценарии SysVinit для управления службами. В этом разделе приведены некоторые рекомендации по преобразованию сценария SysVinit в эквивалент systemd.

Предпосылки

Вы вошли в систему как пользователь с правами администратора.

У вас есть собственный скрипт SysVinit для преобразования в конфигурацию systemd.

Процедура

Определите уровни выполнения в сценарии SysVinit. Обычно это определяется директивой chkconfig в разделе с комментариями в начале скрипта. Например, следующее указывает на то, что служба использует уровни выполнения 3, 4 и 5:

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

Если вы разрешите запускать пользовательскую службу systemd при загрузке ( systemctl enable foo.service ), systemd загружает службу при загрузке multi-user.target при загрузке время.

Определите зависимые службы и цели. Например, если пользовательской службе требуется подключение к сети, укажите network.target в качестве зависимости:

Определите команду, используемую для запуска службы в сценарии SysVinit, и преобразуйте ее в эквивалент systemd. Например, скрипт может содержать функцию запуска в следующем формате:

В этом примере команда /usr/bin/myservice — это пользовательская команда службы, настроенная для демонизации с параметром -D. Установите параметр ExecStart для использования этой команды:

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

В этом примере команда /usr/bin/myservice является пользовательской командой службы и перезагружает службу с помощью подкоманды reload. Установите параметр ExecReload для использования этой команды:

Кроме того, вы можете не использовать ExecReload и использовать поведение по умолчанию, которое завершает работу службы и запускает ее снова.

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

В этом примере команда /usr/bin/myservice является специальной командой службы и корректно останавливает службу с помощью подкоманды shutdown. Установите параметр ExecStop для использования этой команды:

Кроме того, вы можете опустить ExecStop и использовать поведение по умолчанию, которое завершает работу службы.

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

Дополнительная информация

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

Общие параметры сервиса

Параметры объекта

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

Этот список является сводной версией. Чтобы получить полный список этих параметров и их описания, запустите man systemd.unit .

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

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

Аналогично Requires , за исключением того, что сбойные единицы не влияют на службу.

Аналогично Requires, за исключением того, что остановка зависимых единиц также останавливает службу.

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

Список названий объектов, разделенных пробелами, при запуске которых служба не запускается.

Список имен модулей, разделенных пробелами, который настраивает порядок зависимостей между службами.

Список названий объектов, разделенных пробелами, которые активируются, когда эта служба переходит в состояние сбоя.

Установить параметры

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

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

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

Дополнительные модули для установки или удаления при установке или удалении этой службы.

Параметры службы

Этот раздел содержит параметры, которые вы можете использовать в разделе [Сервис] единицы обслуживания. Эти параметры относятся только к сервисным единицам systemd.

Настраивает тип запуска процесса для этой сервисной службы:

простой — служба запускается как основной процесс. Это значение по умолчанию.

forking — служба вызывает разветвленные процессы и запускается как часть основного демона.

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

dbus — аналогично simple , за исключением того, что демон получает имя шины D-Bus.

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

idle — аналогично simple , за исключением того, что выполнение службы откладывается до тех пор, пока не будут отправлены все активные задания.

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

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

Абсолютное имя файла, указывающее на файл PID этого демона. Использование этой опции рекомендуется для сервисов, где Type=forking . Systemd считывает PID основного процесса демона после запуска службы. Systemd не выполняет запись в настроенный здесь файл, но удаляет файл после завершения работы службы.

Имя шины D-Bus для доступа к этой службе. Этот параметр обязателен для служб, где Type=dbus .

Команды и аргументы, выполняемые при запуске службы.

Дополнительные команды, которые выполняются до или после команды в ExecStart.

Команды и аргументы для выполнения при перезагрузке службы.

Команды и аргументы для выполнения при остановке службы.

Дополнительные команды для выполнения после остановки службы.

Время ожидания в секундах перед перезапуском службы.

Время ожидания запуска службы в секундах.

Время ожидания остановки службы в секундах.

Сокращение для одновременной настройки TimeoutStartSec и TimeoutStopSec.

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

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

no — служба не будет перезапущена. Это значение по умолчанию.

при успешном выполнении — перезапуск только после корректного завершения процесса службы (код выхода 0).

on-failure — перезапуск только в том случае, если процесс службы завершается некорректно (код выхода Node-zero).

on-abnormal — перезапуск, если процесс завершается по сигналу или по тайм-ауту.

on-abort — перезапуск, если процесс завершается из-за неперехваченного сигнала, не указанного как чистый статус выхода.

всегда — всегда перезапускать.

Сопоставление уровней выполнения с целями

Цели

Systemd служат той же цели, что и уровни запуска SysVinit, но действуют немного по-другому. У каждой цели есть имя, а не номер, и каждая служит определенной цели.Systemd реализует некоторые цели, наследуя все службы другой цели и добавляя к ней дополнительные службы. Некоторые цели systemd имитируют обычные уровни выполнения sysvinit, что означает, что вы можете переключать цели с помощью знакомой команды telinit RUNLEVEL. Уровни выполнения, которым назначена определенная цель в установках vanilla Fedora (0, 1, 3, 5 и 6), имеют сопоставление 1:1 с определенной целью systemd.

Однако это не относится к определяемым пользователем уровням выполнения 2 и 4. Чтобы использовать эти уровни выполнения, создайте новую цель с именем systemd, например /etc/systemd/system/$YOURTARGET. который использует один из существующих уровней запуска в качестве основы, создайте каталог /etc/systemd/system/$YOURTARGET.wants , а затем создайте символическую ссылку на дополнительные службы, которые нужно включить в этот каталог.

Ниже показано сопоставление уровней выполнения SysVinit с целями systemd.

В Учимся любить systemd, первой статье этой серии, я рассмотрел функции и архитектуру systemd, а также полемику вокруг его роли в качестве замены старой программы инициализации SystemV и сценариев запуска. Во второй статье я начну изучение файлов и инструментов, управляющих последовательностью запуска Linux. Я объясню последовательность запуска systemd, как изменить цель запуска по умолчанию (уровень запуска в терминах SystemV) и как вручную переключиться на другую цель без перезагрузки.

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

Обязательно используйте непроизводственную систему для тестирования и экспериментов в этой и последующих статьях. В вашей тестовой системе должен быть установлен рабочий стол с графическим интерфейсом (например, Xfce, LXDE, Gnome, KDE или другой).

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

Изучение запуска Linux с помощью systemd

Подробнее о системных администраторах

Прежде чем вы сможете увидеть последовательность запуска, вам нужно сделать пару вещей, чтобы сделать последовательности загрузки и запуска открытыми и видимыми. Обычно в большинстве дистрибутивов используется анимация запуска или экран-заставка, чтобы скрыть подробные сообщения, которые в противном случае отображались бы во время запуска и завершения работы хоста Linux. В дистрибутивах на основе Red Hat это называется загрузочным экраном Plymouth. Эти скрытые сообщения могут предоставить системному администратору большой объем информации о запуске и завершении работы, который ищет информацию для устранения ошибки или просто для изучения последовательности запуска. Вы можете изменить это с помощью конфигурации GRUB (Grand Unified Boot Loader).

Основным файлом конфигурации GRUB является /boot/grub2/grub.cfg, но, поскольку этот файл может быть перезаписан при обновлении версии ядра, вы не хотите его изменять. Вместо этого измените файл /etc/default/grub, который используется для изменения настроек grub.cfg по умолчанию.

Начните с просмотра текущей неизмененной версии файла /etc/default/grub:

Глава 6 документации GRUB содержит список всех возможных записей в файле /etc/default/grub, но я сосредоточусь на следующем:

Я изменяю GRUB_TIMEOUT, количество секунд для обратного отсчета меню GRUB, с пяти до 10, чтобы дать немного больше времени для ответа на меню GRUB, прежде чем обратный отсчет достигнет нуля.
Я удаляю два последних параметра в GRUB_CMDLINE_LINUX, в которых перечислены параметры командной строки, которые передаются ядру во время загрузки. Один из этих параметров, rhgb, означает Red Hat Graphical Boot, и он отображает небольшую анимацию значка Fedora во время инициализации ядра вместо отображения сообщений во время загрузки. Другой параметр, тихий, предотвращает отображение сообщений о запуске, которые документируют ход запуска и любые возникающие ошибки. Я удаляю и rhgb, и тихий, потому что системные администраторы должны видеть эти сообщения. Если во время загрузки что-то пойдет не так, отображаемые на экране сообщения могут указать на причину проблемы.

После внесения этих изменений ваш файл GRUB будет выглядеть следующим образом:

Программа grub2-mkconfig создает файл конфигурации grub.cfg, используя содержимое файла /etc/default/grub для изменения некоторых настроек GRUB по умолчанию. Программа grub2-mkconfig отправляет свой вывод в STDOUT. У него есть опция -o, которая позволяет вам указать файл для отправки потока данных, но так же просто использовать перенаправление.Выполните следующую команду, чтобы обновить файл конфигурации /boot/grub2/grub.cfg:

Перезагрузите тестовую систему, чтобы просмотреть сообщения о запуске, которые в противном случае были бы скрыты за анимацией загрузки Plymouth. Но что, если вам нужно просмотреть сообщения о запуске и не отключить анимацию загрузки Plymouth? Или у вас есть, но поток сообщений слишком быстр, чтобы читать? (Что они и делают.)

Есть несколько вариантов, и оба включают файлы журналов и журналы systemd — ваши друзья. Вы можете использовать команду less для просмотра содержимого файла /var/log/messages. Этот файл содержит сообщения о загрузке и запуске, а также сообщения, генерируемые операционной системой при нормальной работе. Вы также можете использовать команду journalctl без каких-либо параметров для просмотра журнала systemd, который содержит практически ту же информацию:

Я усек этот поток данных, поскольку он может состоять из сотен тысяч или даже миллионов строк. (Список журнала на моей основной рабочей станции состоит из 1 188 482 строк.) Обязательно попробуйте это на своей тестовой системе. Если он работал какое-то время — даже если он много раз перезагружался — будут отображаться огромные объемы данных. Изучите данные этого журнала, так как они содержат много информации, которая может оказаться очень полезной при определении проблемы. Зная, как выглядят эти данные при обычной загрузке и запуске, вы сможете обнаружить проблемы, когда они возникнут.

Я расскажу о журналах systemd, команде journalctl и о том, как сортировать все эти данные, чтобы найти то, что вам нужно, более подробно в следующей статье этой серии.

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

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

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

Цели

Цель systemd представляет текущее или желаемое состояние работы системы Linux. Подобно сценариям запуска SystemV, цели определяют службы, которые должны присутствовать, чтобы система работала и была активной в этом состоянии. На рис. 1 показаны возможные цели состояния выполнения системы Linux, использующие systemd. Как видно из первой статьи этой серии и на справочной странице systemd bootup (man bootup), существуют и другие промежуточные цели, необходимые для включения различных необходимых служб. Это могут быть swap.target, timers.target, local-fs.target и другие. Некоторые цели (например, basic.target) используются в качестве контрольных точек, чтобы убедиться, что все необходимые службы запущены и работают, прежде чем переходить к цели следующего более высокого уровня.

Если иное не изменено во время загрузки в меню GRUB, systemd всегда запускает default.target. Файл default.target является символической ссылкой на настоящий целевой файл. Для настольной рабочей станции это обычно будет graphical.target, что эквивалентно уровню выполнения 5 в SystemV. Для сервера по умолчанию, скорее всего, будет multi-user.target, что похоже на уровень запуска 3 в SystemV. Файл Emergency.target аналогичен однопользовательскому режиму. Цели и службы являются единицами systemd.

В следующей таблице, которую я включил в предыдущую статью этой серии, целевые объекты systemd сравниваются со старыми уровнями запуска SystemV. Целевые псевдонимы systemd предоставляются systemd для обратной совместимости. Целевые псевдонимы позволяют сценариям и системным администраторам использовать команды SystemV, такие как init 3, для изменения уровней выполнения. Разумеется, команды SystemV пересылаются в systemd для интерпретации и выполнения.

< td>3 < td>1

цели systemd	уровень запуска SystemV	псевдонимы цели	Описание
default.target	Эта цель всегда псевдоним с символической ссылкой либо на multi-user.target, либо на graphical.target. systemd всегда использует default.target для запуска системы. У default.target никогда не должно быть псевдонима halt.target, poweroff.target или reboot.target.
graphical.target	5	runlevel5.target	Многопользовательский.target с графическим интерфейсом
4	runlevel4.target	Не используется. Уровень выполнения 4 был идентичен уровню выполнения 3 в мире SystemV. Эту цель можно создать и настроить для запуска локальных служб без изменения многопользовательской.цели по умолчанию.
многопользовательская.цель	уровень запуска3.target	Все службы запущены, но только интерфейс командной строки (CLI)
2	runlevel2. target	Многопользовательский, без NFS, но работают все остальные службы без графического интерфейса пользователя
rescue.target	runlevel1.target	Базовая система, включая монтирование файловых систем с запущенными только самыми основными службами и аварийной оболочкой на главной консоли
emergency.target	S	Однопользовательский режим — службы не запущены; файловые системы не монтируются. Это самый базовый уровень работы, когда на главной консоли работает только аварийная оболочка, позволяющая пользователю взаимодействовать с системой.
halt.target< /td>	Остановка системы без отключения питания
reboot.target	6	runlevel6.target	Перезагрузка
poweroff.target	0	runlevel0. target	Остановка системы и отключение питания

Рис. 1: Сравнение уровней выполнения SystemV с целями systemd и псевдонимами целей.

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

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

Многие дистрибутивы Linux по умолчанию устанавливают графический интерфейс рабочего стола, чтобы установленные системы можно было использовать в качестве рабочих станций. Я всегда устанавливаю с загрузочного USB-накопителя Fedora Live с рабочим столом Xfce или LXDE. Даже когда я устанавливаю сервер или хост другого типа инфраструктуры (например, те, которые я использую для маршрутизаторов и брандмауэров), я использую одну из этих установок, которая устанавливает рабочий стол с графическим интерфейсом.

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

Но то, что у меня есть рабочий стол с графическим интерфейсом, не означает, что его использование имеет смысл. У меня есть 16-портовый KVM, который я могу использовать для доступа к KVM-интерфейсам большинства моих Linux-систем, но в подавляющем большинстве случаев я взаимодействую с ними через удаленное SSH-соединение с моей основной рабочей станции. Этот способ более безопасен и использует меньше системных ресурсов для запуска multi-user.target по сравнению с graphical.target.

Для начала проверьте цель по умолчанию, чтобы убедиться, что это graphical.target:

Теперь проверьте текущую работающую цель. Он должен быть таким же, как цель по умолчанию. Вы по-прежнему можете использовать старый метод, который отображает старые уровни запуска SystemV. Обратите внимание, что предыдущий уровень запуска находится слева; это N (что означает «Нет»), указывающий, что уровень запуска не изменился с момента загрузки хоста. Число 5 указывает текущую цель, как определено в старой терминологии SystemV:

Обратите внимание, что на справочной странице уровня запуска указано, что уровни запуска устарели, и приведена таблица преобразования.

Вы также можете использовать метод systemd. Здесь нет однострочного ответа, но он дает ответ в терминах systemd:

Показывает все загруженные и активные цели. Вы также можете увидеть graphical.target и multi-user.target. Multi-user.target требуется перед загрузкой graphical.target. В этом примере graphical.target активен.

Переключение на другую цель

Переключиться на multi-user.target очень просто:

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

Обязательно используйте команду уровня запуска, чтобы убедиться, что она показывает как предыдущие, так и текущие «уровни выполнения»:

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

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

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

В этом списке вы должны увидеть файлы, каталоги и другие ссылки, но обратите особое внимание на multi-user.target и graphical.target.Теперь отобразите содержимое default.target, которое является ссылкой на /lib/systemd/system/graphical.target:

Эта ссылка на файл graphical.target описывает все предпосылки и требования, предъявляемые к графическому пользовательскому интерфейсу. Я рассмотрю хотя бы некоторые из этих вариантов в следующей статье этой серии.

Чтобы узел мог загружаться в многопользовательском режиме, необходимо удалить существующую ссылку и создать новую, указывающую на правильную цель. Создайте PWD /etc/systemd/system, если это еще не сделано:

Укажите ссылку default.target, чтобы убедиться, что она ведет к правильному файлу:

Если ваша ссылка выглядит иначе, удалите ее и повторите попытку. Перечислите содержимое ссылки default.target:

Файл default.target, который на данный момент является ссылкой на multi-user.target, теперь имеет другие требования в разделе [Unit]. Для этого не требуется диспетчер графического отображения.

Перезагрузить. Ваша виртуальная машина должна загружаться с логином консоли для виртуальной консоли 1, которая обозначена на дисплее как tty1. Теперь, когда вы знаете, как изменить цель по умолчанию, измените ее обратно на graphical.target с помощью команды, предназначенной для этой цели.

Сначала проверьте текущую цель по умолчанию:

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

Я не знаю, почему разработчики systemd выбрали термин "изолировать" для этой подкоманды. Мое исследование показывает, что это может относиться к запуску указанной цели, но «изоляции» и прекращению всех других целей, которые не требуются для поддержки цели. Однако результатом является переключение целей с одной цели выполнения на другую — в данном случае с многопользовательской цели на графическую цель. Приведенная выше команда эквивалентна старой команде init 5 в сценариях запуска SystemV и программе инициализации.

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

Подведение итогов

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

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

Ресурсы

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

В проекте Fedora есть хорошее практическое руководство по systemd. В нем есть почти все, что вам нужно знать для настройки, управления и обслуживания компьютера Fedora с помощью systemd.
В проекте Fedora также есть хорошая шпаргалка, в которой старые команды SystemV ссылаются на сопоставимые команды systemd.
Для получения подробной технической информации о systemd и причинах его создания ознакомьтесь с описанием systemd на Freedesktop.org. "Больше удовольствия от systemd" содержит более подробную информацию и советы по systemd.

Есть также серия технических статей для системных администраторов Linux, написанных Леннартом Поттерингом, дизайнером и основным разработчиком systemd. Эти статьи были написаны в период с апреля 2010 года по сентябрь 2011 года, но сейчас они так же актуальны, как и тогда. Большая часть всего хорошего, что было написано о systemd и его экосистеме, основано на этих документах.

Учимся любить systemd

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

Почему systemd является практичным инструментом для системных администраторов

Я встретил Элисон Чайкен на LinuxCon 2010 в Бостоне, вскоре после того, как она присоединилась к Nokia в качестве технического консультанта Meego. Несколько месяцев спустя я взял у нее интервью о ее роли в Nokia.

Systemd — это система, разработанная специально для ядра Linux. Он заменяет процесс sysvinit и становится первым процессом с PID = 1, который запускается в пользовательском пространстве во время запуска Linux.

Почему systemd?

Это один из первых вопросов, который приходит на ум при обсуждении systemd.Чтобы найти ответ, мы должны сначала немного узнать о sysvinit. Если забыть о systemd и других подобных системах, то можно с уверенностью сказать, что sysvinit — это первый процесс, запускаемый ядром при загрузке любого компьютера с Linux или Unix. Это означает, что все остальные процессы так или иначе являются их дочерними процессами.

После успешной загрузки системы процесс sysvinit продолжает работать и ожидает специальных команд, таких как «shutdown», которые используются для завершения работы системы Linux. Это означает, что теперь задача процесса sysvinit состоит в корректном завершении работы системы. В течение многих лет sysvinit оставался идеальной системой для включения и выключения систем на базе Linux. Но со временем система стала медленной и негибкой, особенно для современных компьютеров.

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

Как установить systemd

Он предустановлен в различных ОС на базе Linux, таких как Arch, Debian, Fedora и Ubuntu.

Тем не менее, вы также можете установить его вручную.

Проверить текущую версию systemd:

Получить обновление tar:

Извлечь файл:

Мы используем ключ -J для извлечения пакета:

Подготовка к установке:

Необходимо установить следующие пакеты для лучшей установки

Теперь введите эти команды:

Теперь настроим пакет

Установить:

Управление службами с помощью systemd:

systemctl: управляет системой и службами systemd.
journalctl: используется для управления журналом, собственной системой журналирования systemd.
hostnamectl: может управлять именем хоста.
localectl: помогает настроить локальную систему и раскладку клавиатуры.
timedatectl: используется для установки времени и даты.
systemd-cgls: показывает содержимое cgroup.
systemadm: это интерфейс для команды systemctl.

Например:

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

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

Лицензия

Эта программа является бесплатным программным обеспечением; вы можете распространять его и/или изменять в соответствии с условиями Стандартной общественной лицензии ограниченного применения GNU, опубликованной Free Software Foundation; либо версия 2.1 Лицензии, либо (на ваш выбор) любая более поздняя версия. Эта программа распространяется в надежде, что она будет полезна, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ; даже без подразумеваемой гарантии КОММЕРЧЕСКОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ. Дополнительные сведения см. в Стандартной общественной лицензии ограниченного применения GNU.

Правописание

Да, пишется systemd, а не system D или System D, и даже не SystemD. И это не system d. Почему? Потому что это системный демон, а в Unix/Linux они написаны строчными буквами и имеют суффикс d в нижнем регистре. И поскольку systemd управляет системой, он называется systemd. Это так просто. Но опять же, если все это кажется вам слишком простым, назовите это (но никогда не произносите!) Системой пятисот, поскольку D — это римская цифра, обозначающая 500 (это также проясняет отношение к Системе V, верно?). Единственная ситуация, когда мы считаем допустимым использовать заглавную букву в имени (но нам это тоже не нравится), — это если вы начинаете предложение с systemd. В праздничные дни вы также можете написать это sÿstëmd.Но опять же, Système D — это неприемлемое написание и нечто совершенно другое (хотя и подходящее).

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

systemd вызывает споры по нескольким причинам: это замена чего-то, что, по мнению многих пользователей Linux, не нуждается в замене, а выходки разработчиков systemd не завоевали сердца и умы. Скорее наоборот, о чем свидетельствует знаменитая ветка LKML, где Линус Торвальдс запретил разработчику systemd Кею Сиверсу доступ к ядру Linux.

Заманчиво позволить личностям встать у вас на пути. Как бы ни было весело разглагольствовать, ругаться и произносить красочные эпитеты, это не относится к делу. В течение стольких лет Linux довольствовался SysVInit и BSD init. Затем появились дополнительные менеджеры служб, такие как команды service и chkconfig. Предполагалось, что это упростит управление услугами, но для меня это было просто дополнительными вещами, которые не облегчали задачи, а скорее усложняли задачу.

Затем появились Upstart и systemd со всевозможными замысловатыми надстройками для обеспечения совместимости с SysVInit. Это хорошо, но удачи в понимании этого. Теперь Upstart уходит на пенсию в пользу systemd, вероятно, в Ubuntu 14.10, и вы найдете массу библиотек и инструментов для systemd в 14.04. Просто для смеха посмотрите на список файлов в пакете systemd -services в Ubuntu 14.04:

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

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

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

Первые шаги

Red Hat является изобретателем и основным сторонником systemd , поэтому лучшими дистрибутивами для работы с ним являются Red Hat Enterprise Linux, клоны RHEL, такие как CentOS и Scientific Linux, и, конечно же, старая добрая Fedora Linux, которая всегда поставляется с последней версией. , величайший и самый кроваво-острый. Мои примеры взяты из CentOS 7.

Опытные пользователи RH по-прежнему могут использовать сервис и chkconfig в RH 7, но давно пора отказаться от них в пользу родных утилит systemd. systemd опередил их, а service и chkconfig не поддерживают собственные службы systemd.

Нашего любимого файла /etc/inittab больше нет. Вместо этого у нас есть каталог /etc/systemd/system/, битком набитый символическими ссылками на файлы в /usr/lib/systemd/system/. /usr/lib/systemd/system/ содержит сценарии инициализации; чтобы запустить службу при загрузке, она должна быть связана с /etc/systemd/system/. Команда systemctl делает это за вас, когда вы включаете новую службу, как в этом примере для ClamAV:

Откуда вы знаете имя сценария инициализации и откуда оно берется? В Centos7 они разбиты на отдельные пакеты. Многие сервера (например Apache) не догнали systemd и не имеют скриптов инициализации systemd. ClamAV предлагает сценарии инициализации systemd и SysVInit, так что вы можете установить тот, который предпочитаете:

Так что же внутри этих сценариев инициализации? Мы можем убедиться сами:

Теперь вы можете видеть, как systemctl знает, куда установить символическую ссылку, и этот сценарий инициализации также включает зависимость от другой службы, clamd@.service .

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

У службы есть три возможных состояния: включено или отключено, а также статично. Включено означает, что у него есть символическая ссылка в каталоге .wants. Отключено значит нет. Статический означает, что в сценарии инициализации службы отсутствует раздел [Install], поэтому вы не можете включить или отключить его. Статические службы обычно являются зависимостями от других служб и управляются автоматически. Вы можете увидеть это в примере с ClamAV, так как clamd@.service является зависимостью от clamd@scan.service и запускается только при запуске clamd@scan.service.

Ни одно из этих состояний не говорит о том, что служба запущена. Команда ps сообщит вам или используйте systemctl для получения более подробной информации:

systemctl скажет вам все, что вы хотите знать, если вы знаете, как спросить.

Шпаргалка

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

Цель: группа объектов
Автомонтирование: точка автоматического монтирования файловой системы
Устройство: имена устройств ядра, которые можно увидеть в sysfs и udev.
Mount: точка монтирования файловой системы
Путь: файл или каталог
Область действия: внешние процессы, не запущенные systemd
Срез: единица управления процессами
Снимок: сохраненное состояние systemd
Сокет: сокет IPC (межпроцессное взаимодействие).
Обмен: файл подкачки
Таймер: системный таймер.

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

Игра с обвинением

По какой-то причине кажется, что сторонники замены SysVInit одержимы временем загрузки. Мои системы systemd, такие как CentOS 7, загружаются не намного быстрее, чем другие. В любом случае это не то, что меня особенно волнует, поскольку большинство измерений скорости загрузки измеряют только достижение запроса на вход в систему, а не то, сколько времени требуется, чтобы система полностью запустилась и стала пригодной для использования. Microsoft Windows долгое время была лидером в этом отношении, довольно быстро достигая приглашения для входа в систему, а затем тратя еще несколько минут на загрузку и запуск вредоносного, коммерческого, шпионского ПО и почти всего, кроме того, что вам нужно. (Клянусь, если я увижу еще один дурацкий экран ворчащего средства обновления Oracle Java, я стану жестоким.)

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

И еще несколько десятков. Ну вот и все на сегодня, друзья. systemd уже очень сложный зверь; обратитесь к разделу «Ссылки», чтобы узнать больше.

Читайте также: