Как открыть systemd в линуксе
Управление сервисами в Linux. Команда systemctl
Что такое сервисы в Linux
Сервисы или службы — это программы, которые работают в системе Linux в фоновом режиме. Обычно они запускаются при загрузке системы. Большинство сервисов необходимы для полноценной работы системы, то есть они являются своего рода кирпичиками, из которых строится работающая система.
При запуске системы загружается целый ряд сервисов, которые включены для автозагрузки. Сервисы работают пока система запущена, и выгружаются при выключении системы.
Чаще всего в Linux дистрибутивах для инициализации сервисов используется демон Systemd. К Systemd-дистрибутивам относятся Ubuntu, Debian, Linux Mint, Fedora, openSUSE, Solus и другие.
Есть дистрибутивы, которые не используют Systemd. Вместо Systemd могут использоваться такие системы инициализации, как Upstart, SysV.
В качестве примеров сервисов можно привести: веб-сервер Apache, Network Manager, файрвол Ufw и другие.
Список сервисов
Чтобы просмотреть список всех сервисов можно воспользоваться командой:
Данная команда пробегает по алфавитному списку всех доступных сервисов и выполняет для них команду status.
В выводе команды используются следующие обозначения:
Запуск сервиса
Для запуска сервиса используется команда systemctl start имя_сервиса
Останов сервиса
Для остановки сервиса используется команда systemctl stop имя_сервиса
Перезапуск сервиса
Перезапуск сервиса выполняется командой systemctl restart имя_сервиса
Обычно перезапуск конкретного сервиса требуется, когда были изменены настройки данного сервиса.
Автозагрузка сервисов
Чтобы сервис стартовал (загружался) при запуске системы, его нужно включить в список автозагрузки. Для этого используется команда systemctl enable имя_сервиса
Чтобы включить сервис в автозапуск и сразу же запустить используется команда:
Чтобы удалить сервис из автозагрузки, используется команда systemctl disable имя_сервиса
Статус сервиса
Для вывода информации (статуса) сервиса используется команда systemctl status имя_сервиса
Чтобы проверить, запущен ли в данный момент сервис, используется команда systemctl is-active имя_сервиса
Чтобы проверить, включен ли сервис для автозапуска при загрузке системы, используется команда systemctl is-enabled имя_сервиса
Заключение
Мы рассмотрели наиболее часто используемые команды утилиты systemctl. Полный список команд и опций утилиты systemctl можно получить, выполнив:
Шпаргалка по управлению сервисами CentOS 7 с systemd
Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.
В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет — оставим за кадром.
В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7.
Введение
Основные функции systemd в CentOS 7
Управление сервисами
В предыдущих версиях CentOS использовалась SysV или Upstart. Скрипты инициализации располагались в директории /etc/rc.d/init.d/. Такие скрипты обычно писались на Bash и позволяли администратору управлять состоянием сервисов и демонов. В CentOS 7 скрипты инициализации были заменены сервисными юнитами.
По способу использования сервисные юниты .service напоминают скрипты инициализации. Для просмотра, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl. Команды service и chkconfig по-прежнему включены в систему, но только по соображениям совместимости.
При использовании systemctl указывать расширение файла не обязательно.
Работаем с целями (targets) Systemd
Предыдущие версии CentOS с SysV init или Upstart включали предопределенный набор уровней запуска (runlevels), которые представляли специфичные режимы для операций, пронумерованные от 0 до 6. В CentOS 7 концепция уровней запуска была заменена целями systemd.
Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например юнит graphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.
В CentOS 7 присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют алиасы на эти цели, которые напрямую отображаются в уровнях запуска SysV.
Для определения, какой целевой юнит используется по умолчанию, полезна следующая команда: systemctl get–default.
Для изменения цели по умолчанию поможет команда systemctl set-default name.target.
Для изменения текущей цели: systemctl isolate name.target. Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.
Выключение и перезагрузка системы
В CentOS 7 systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомандуется использовать systemctl:
systemctl halt – останавливает систему
systemctl poweroff – выключает систему
systemctl reboot – перезагружает систему
Управление systemd на удаленной машине
Давайте посмотрим на секцию [Unit]. Она содержит общую информацию о сервисе. Такая секция есть не только в сервис-юнитах, но и в других юнитах (например при управлении устройствами, точками монтирования и т.д.). В нашем примере мы даем описание сервиса и указываем на то, что демон должен быть запущен после Syslog.
В следующей секции [Service] непосредственно содержится информация о нашем сервисе. Используемый параметр ExecStart указывает на исполняемый файл нашего сервиса. В Type мы указываем, как сервис уведомляет systemd об окончании запуска.
Финальная секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target.
Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/имя_сервиса.service. Выполните команды systemctl daemon-reload. Systemd узнает о сервисе и вы сможете его запустить.
Дополнительная информация
Заключение
В этой статье мы научились управлять сервисами CentOS 7. Конечно, это далеко не единственная функция systemd и другие ее стороны будут рассмотрены в будущем. Сама ОС практически со времени релиза доступна на классических VPS и облачных VPS от Infobox. Попробуйте systemd прямо сейчас. Эти знания будут полезны в связи с переходом многих дистрибутивов на systemd.
Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней.
В случае, если вы не можете оставлять комментарии на Хабре, можно написать их в блоге Сообщества InfoboxCloud или в нашей группе в Facebook.
Systemd за пять минут
Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).
В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.
Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…
Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.
Systemd запускает сервисы описанные в его конфигурации.
Конфигурация состоит из множества файлов, которые по-модному называют юнитами.
Все эти юниты разложены в трех каталогах:
/usr/lib/systemd/system/ – юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее
/run/systemd/system/ — юниты, созданные в рантайме — тоже, наверное, нужная штука
/etc/systemd/system/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.
[Название секции в квадратных скобках]
имя_переменной = значение
Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]
В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:
Далее следует блок переменных, которые влияют на порядок загрузки сервисов:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса
В секции Service указываем какими командами и под каким пользователем надо запускать сервис:
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Данный тип используется для запуска классических демонов.
Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:
Команды на старт/стоп и релоад сервиса
Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.
Таймаут в секундах, сколько ждать system отработки старт/стоп команд.
Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла
В секции [Install] опишем, в каком уровне запуска должен стартовать сервис
multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»
Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service
Кладем этот файл в каталог /etc/systemd/system/
Смотрим его статус systemctl status myunit
Если нет никаких ошибок в юните — то вывод будет вот такой:
Использование 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 :
Например, для перезагрузки системы обычно можно ввести следующее:
Заключение
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, т.е.:
Также у нас имеется «лицензия на убийство»
Хотите перезапустить все юниты и перестроить дерево зависимостей? Не проблема
