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/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.
Юнит представляет из себя текстовый файл с форматом, похожим на файлы .ini Microsoft Windows.
[Название секции в квадратных скобках]
имя_переменной = значение
Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]
В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:
Description=MyUnit
Далее следует блок переменных, которые влияют на порядок загрузки сервисов:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
Для запуска сервиса необходим запущенный сервис mysql:
Requires=mysql.service
Для запуска сервиса желателен запущенный сервис redis:
Wants=redis.service
В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса
В секции Service указываем какими командами и под каким пользователем надо запускать сервис:
Type=simple
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
Type=forking
systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Данный тип используется для запуска классических демонов.
Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:
PIDFile=/work/www/myunit/shared/tmp/pids/service.pid
Рабочий каталог, он делается текущим перед запуском стартап команд:
WorkingDirectory=/work/www/myunit/current
Пользователь и группа, под которым надо стартовать сервис:
User=myunit
Group=myunit
Environment=RACK_ENV=production
Запрет на убийство сервиса вследствие нехватки памяти и срабатывания механизма OOM:
-1000 полный запрет (такой у sshd стоит), -100 понизим вероятность.
OOMScoreAdjust=-100
Команды на старт/стоп и релоад сервиса
ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb —daemon
ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop
ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart
Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.
Таймаут в секундах, сколько ждать system отработки старт/стоп команд.
TimeoutSec=300
Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла
Restart=always
В секции [Install] опишем, в каком уровне запуска должен стартовать сервис
WantedBy=multi-user.target
multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»
Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service
[Unit] Description=MyUnit After=syslog.target After=network.target After=nginx.service After=mysql.service Requires=mysql.service Wants=redis.service [Service] Type=forking PIDFile=/work/www/myunit/shared/tmp/pids/service.pid WorkingDirectory=/work/www/myunit/current User=myunit Group=myunit Environment=RACK_ENV=production OOMScoreAdjust=-1000 ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart TimeoutSec=300 [Install] WantedBy=multi-user.target Кладем этот файл в каталог /etc/systemd/system/
Смотрим его статус systemctl status myunit
myunit.service - MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; disabled) Active: inactive (dead) Видим, что он disabled — разрешаем его
systemctl enable myunit
systemctl -l status myunit
Если нет никаких ошибок в юните — то вывод будет вот такой:
myunit.service - MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; enabled) Active: inactive (dead) Запускаем сервис
systemctl start myunit
Смотрим красивый статус:
systemctl -l status myunit
Если есть ошибки — читаем вывод в статусе, исправляем, не забываем после исправлений в юните перегружать демон systemd
systemctl daemon-reload
Теперь, после ознакомительного окунания в systemd можно, начинать самостоятельные заплывы.
Если вдруг появятся вопросы, рады будем ответить на ваши письма по адресу ask@centos-admin.ru
Использование Systemctl для управления службами и блоками Systemd
systemd — это система инициализации и системный диспетчер, который стал новым стандартом для дистрибутивов Linux. Из-за сложной адаптивности знакомство с системой systemd оправдано, поскольку это существенно упростит администрирование серверов. Изучение и использование инструментов и демонов, которые включают systemd , поможет вам лучше оценить предоставляемые возможности и гибкость или, по крайней мере, работать с минимальным количеством проблем.
В этом руководстве мы обсудим команду systemctl , которая является инструментом центрального управления для контроля системы инициализации. Мы расскажем о том, как управлять службами, проверять статус, изменять состояние системы и работать с файлами конфигурации.
Обратите внимание, что хотя система systemd стала системой инициализации по умолчанию для многих дистрибутивов Linux, она не используется повсеместно во всех дистрибутивах. По мере изучения этого руководства, если ваш терминал выводит ошибку bash: systemctl is not installed , скорее всего, на вашей машине установлена другая система инициализации.
Управление службами
Основополагающая цель системы инициализации заключается в инициализации компонентов, которые должны запускаться после загрузки ядра Linux (традиционно называются компоненты пользовательского пространства). Система инициализации также используется для управления службами и демонами для сервера и в любой момент времени работы системы. С учетом этого мы начнем с нескольких базовых операций по управлению службами.
В systemd целью большинства действий являются «модули», являющиеся ресурсами, которыми 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/ some_target .target.wants ; что такое цель, мы рассмотрим далее в этом руководстве).
Чтобы отключить автоматический запуск службы, можно ввести следующее:
При этом будет удалена символическая ссылка, что укажет на то, что служба не должна запускаться автоматически.
Помните, что включение службы не запустит ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, необходимо дать обе команды, start и enable .
Проверка статуса служб
Чтобы проверить статус службы в вашей системе, можно использовать команду status :
При этом вы получите статус службы, иерархию контрольных групп и первые несколько строк журнала.
Например, при проверке статуса сервера Nginx вы можете видеть следующий вывод:
Output● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server. Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server. Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий.
Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду is-active :
Это вернет текущий статус модуля, который обычно active или inactive . Код выхода будет «0», если он активен, и результат будет проще парсить в скрипты оболочки.
Чтобы увидеть, включен ли модуль, можно использовать команду is-enabled :
Это выведет информацию о том, что служба enabled или disabled , и снова установит код выхода на «0» или «1» в зависимости от вопроса команды.
Третья проверка заключается в проверке того, находится ли модуль в состоянии сбоя. Это означает, что была проблема, которая запустила данный модуль:
Это вернет active , если он работает должным образом, или failed , если возникла ошибка. Если модуль был намеренно остановлен, может вернуться unknown или inactive . Статус выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на какой-либо другой статус.
Обзор состояния системы
Команды до сих пор были полезны для управления отдельными службами, но они не очень подходят для понимания текущего состояния системы. Существует ряд команд systemctl , предоставляющих эту информацию.
Список текущих модулей
Чтобы увидеть список всех активных модулей, о которых знает systemd , можно использовать команду list-units :
Это покажет вам список всех модулей, которые у systemd активны в системе. Результат будет выглядеть примерно так:
OutputUNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System getty@tty1.service loaded active running Getty on tty1 . . . Вывод содержит следующие столбцы:
- UNIT: имя модуля systemd
- LOAD: указывает на то, парсила ли systemd конфигурацию модуля. Конфигурация загруженных модулей сохраняется в памяти.
- ACTIVE: краткое состояние активности модуля. Обычно это довольно стандартный способ сообщить, запущен модуль или нет.
- SUB: это состояние более низкого уровня, которое указывает более подробную информацию о модуле. Это часто зависит от типа модуля, состояния и фактического метода работы модуля.
- DESCRIPTION: краткое текстовое описание того, чем является модуль/что делает.
Поскольку команда list-units показывает по умолчанию только активные модули, для всех вводов выше отобразится loaded в столбце LOAD и active в столбце ACTIVE. Это отображение фактически является поведением по умолчанию systemctl при вызове без дополнительных команд, поэтому вы увидите то же, что и при вызове systemctl без аргументов:
Мы можем использовать systemctl для вывода различной информации путем добавления дополнительных флагов. Например, чтобы увидеть все модули, которые загрузила система systemd (или пыталась загрузить), независимо от их активности в данный момент, можно использовать следующий флаг —all :
Это отобразит все модули, которые загрузила или пыталась загрузить система systemd независимо от текущего состояния системы. Некоторые модули становятся неактивными после работы, а некоторые модули, которые система systemd пыталась загрузить, могут не быть найдены на диске.
Вы можете использовать другие флаги для фильтрации этих результатов. Например, мы можем использовать флаг —state= для указания состояния LOAD, ACTIVE или SUB, которое мы хотим увидеть. Вам потребуется сохранить флаг —all , чтобы systemctl позволила отображать неактивные модули:
Другим распространенным фильтром является фильтр — —type= . Мы можем задать systemctl только для отображения модулей интересующего нас типа. Например, чтобы увидеть только активные модули службы, мы можем:
Список все файлов модулей
Команда list-units отображает только модули, которые система systemd пыталась парсить или загрузить в память. Поскольку systemd будет считывать только те модули, которые считает необходимыми, это необязательно будут все модули, доступные в системе. Чтобы увидеть все доступные файлы модулей в путях systemd , включая те, что система systemd пыталась загрузить, можно использовать команду list-unit-files :
Модули являются представлениями ресурсов, о которых знает systemd . Поскольку система systemd необязательно считывала все определения модуля в этом виде, она представляет информацию только о самих файлах. Вывод содержит два столбца: файл модуля и состояние.
OutputUNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . . Состояние будет, как правило, enabled , disabled , static или masked . В этом контексте static обозначает, что файл модуля не содержит раздел install , который используется для включения модуля. Эти модули как таковые не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость другого модуля и не должен работать самостоятельно.
Мы рассмотрим сразу же, что означает masked .
Управление модулями
До сих пор мы работали со службами и отображали информацию о модулях и файлах модулей, о которых знает systemd . Однако мы можем узнать более конкретную информацию о модулях, используя некоторые дополнительные команды.
Отображение файла модуля
Чтобы отобразить файл модуля, который система systemd загрузила в систему, можно использовать команду cat (она была добавлена в версию systemd 209). Например, чтобы увидеть файл модуля демона-планировщика atd , можно ввести следующее:
Output[Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target Вывод — это файл модуля, известный выполняемому в настоящее время процессу systemd . Это может быть важно, если вы недавно модифицировали файлы модуля или если вы переопределяете определенные опции во фрагменте файла модуля (мы рассмотрим это позже).
Отображение зависимостей
Чтобы увидеть дерево зависимостей модуля, можно использовать команду list-dependencies :
При этом отобразится иерархическая схема зависимостей, с которой необходимо работать, чтобы запустить интересуемый модуль. Зависимости в этом контексте включают те модули, которые либо требуются, либо желательны для модулей выше.
Outputsshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . . Рекурсивные зависимости отображаются только для модулей .target , которые указывают состояние системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг —all .
Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флаг —reverse . Другие полезные флаги —before и —after могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно, перед ними и после.
Проверка свойств модуля
Чтобы увидеть свойства более низкого уровня модуля, можно использовать команду show . При этом будет выведен список свойств, заданных для указанного модуля с помощью формата key=value :
OutputId=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . . . Если вы хотите отобразить одно свойство, можно передать флаг -p с именем свойства. Например, чтобы увидеть конфликты, которые есть у модуля sshd.service , можно ввести следующее:
OutputConflicts=shutdown.target Маскировка и снятие маскировки модулей
В разделе управления службами мы узнали, как остановить или отключить службу, но systemd также имеет возможность отметить модуль как полностью незапускаемый, автоматически или вручную, связав его с /dev/null . Это называется маскировкой модуля, и она возможна с помощью команды mask :
Это не позволит запустить службу Nginx автоматически или вручную, пока она замаскирована.
Если вы проверите list-unit-files , вы увидите, что служба теперь указана как замаскированная:
Output. . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . . Если вы попытаетесь запустить службу, вы увидите следующее сообщение:
OutputFailed to start nginx.service: Unit nginx.service is masked. Чтобы снять маскировку модуля и сделать его доступным для использования снова, используйте команду unmask :
Это вернет модуль в его предыдущее состояние, что позволит его запускать или включать.
Редактирование файлов модулей
Хотя конкретный формат файлов модулей выходит за рамки этого руководства, systemctl предоставляет встроенные механизмы для редактирования и модификации файлов модулей при необходимости изменений. Эта функция добавлена в версию systemd 218.
Команда edit по умолчанию откроет фрагмент файла модуля для интересующего модуля:
Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение модуля. Каталог будет создан в каталоге /etc/systemd/system , который содержит название модуля с добавлением .d . Например, для nginx.service будет создан каталог под названием nginx.service.d .
В этом каталоге будет создан фрагмент под названием override.conf . При загрузке модуля systemd в памяти соединит фрагмент переопределения с полным файлом модуля. Директивы фрагмента получат приоритет над найденными в оригинальном файле модуля.
Если вы хотите редактировать весь файл модуля, а не создавать фрагмент, можно передать флаг —full :
Это загрузит текущий файл модуля в редактор, где его можно редактировать. После выхода из редактора измененный файл будет записан в /etc/systemd/system , что будет иметь приоритет над определением модуля системы (обычно находится где-то в /lib/systemd/system ).
Чтобы удалить какие-либо сделанные добавления, удалите либо каталог конфигурации модуля .d или модифицированный служебный файл из /etc/systemd/system . Например, для удаления фрагмента можно ввести следующее:
Чтобы удалить весь отредактированный файл модуля, добавим:
После удаления файла или каталога необходимо перезагрузить процесс systemd , чтобы он больше не пытался ссылаться на эти файлы и не возвращался к использованию системных копий. Для этого можно ввести следующую команду:
Настройка состояния системы (уровень запуска) с помощью целей
Целями являются специальные файлы модулей, которые описывают состояние системы или точку синхронизации. Как и другие модули, файлы, которые определяют цели, могут быть идентифицированы по суффиксу, которым в данном случае является .target . Цели сами по себе немного значат, а используются для группировки других модулей.
Их можно использовать, чтобы привести систему в определенные состояния, подобно тому, как другие системы инициализации используют уровни запуска. Они используются в качестве справки, когда доступны определенные функции, позволяя вам указывать желаемое состояние вместо необходимости использования отдельных модулей для получения этого состояния.
Например, swap.target используется для указания того, что переключение готово к использованию. Модули, являющиеся частью этого процесса, могут синхронизироваться с этой целью путем указания в своей конфигурации, что они WantedBy= или RequiredBy= swap.target . Модули, которым требуется возможность переключения, могут указывать это состояние с помощью спецификаций Wants= , Requires= и After= для указания характера их отношений.
Получение и настройка цели по умолчанию
Процесс systemd имеет цель по умолчанию, которую он использует при загрузке системы. Удовлетворение каскада зависимостей от этой одной цели приведет систему в желаемое состояние. Чтобы найти цель по умолчанию для вашей системы, введите:
Outputmulti-user.target Если вы хотите задать другую цель по умолчанию, можно использовать set-default . Например, если у вас установлен графический рабочий стол и вы хотите загрузить систему в него по умолчанию, можно изменить цель по умолчанию соответственно:
Список доступных целей
Вы можете получить список имеющихся целей в вашей системе, введя:
В отличие от уровней запуска, несколько целей могут быть активны одновременно. Активная цель указывает, что система systemd попыталась запустить все модули, привязанные к цели, и не попыталась закрыть их снова. Чтобы увидеть все активные цели, введите:
Изолирование целей
Можно запустить все модули, связанные с целью, и остановить все модули, не являющиеся частью дерева зависимостей. Команда, необходимая для этого, называется соответственно isolate . Она аналогична изменению уровня запуска в других системах инициализации.
Например, если вы работаете в графической среде с активным graphical.target , можно закрыть графическую систему и перевести систему в состояние многопользовательской командной строки путем изоляции multi-user.target . Поскольку graphical.target зависит от multi-user.target , а не наоборот, все графические модули будут остановлены.
Возможно, вы захотите посмотреть на зависимости цели, которую вы изолируете, перед выполнением этой процедуры, чтобы убедиться, что не остановлены важные службы:
Если вы удовлетворены модулями, которые будут сохранены в активном состоянии, можно изолировать цель, введя:
Использование комбинации быстрого ввода для важных событий
Для таких важных событий, как отключение или перезагрузка, определены цели. Однако для systemctl также есть несколько комбинаций быстрого ввода, обеспечивающих дополнительную функциональность.
Например, чтобы перевести систему в режим спасения (один пользователь), можно использовать команду rescue вместо isolate rescue.target :
Это обеспечит дополнительную функцию предупреждения всех подключенных пользователей о событии.
Чтобы остановить систему, можно использовать команду halt :
Для инициализации полного отключения можно использовать команду poweroff :
Перезапуск можно начать с помощью команды reboot :
Все это оповестит подключенных пользователей о том, что происходит событие, что-то, что только выполняет или изолирует цель, не сработает. Обратите внимание, что большинство машин будет привязывать более короткие, более традиционные команды для этих операций, чтобы правильно работать с systemd .
Например, для перезагрузки системы обычно можно ввести следующее:
Заключение
К этому моменту вы должны уже ознакомиться с некоторыми базовыми возможностями команды systemctl , которая позволяет взаимодействовать и контролировать экземпляр systemd . Утилита systemctl будет главной точкой взаимодействия для управления службами и состоянием системы.
Хотя systemctl работает главным образом с основным процессом systemd , в экосистеме systemd есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и сеансы пользователя, обрабатываются отдельными демонами и утилитами управления ( journald / journalctl и logind / loginctl соответственно). Знакомство с этими другими инструментами и демонами упростит задачу управления.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Что такое systemctl? Управление службами в Linux
В основе работы любой серверной системы лежит взаимодействия между ее службами. Даже если вы простой пользователь знать о принципах их работы будет полезным приобретением. В этой статье разберем базовые понятия об функционировании служб в системах с Linux, популярные и наиболее часто используемые команды для контроля над ними.
Перед там как перейти к systemctl начнем с того что такое systemd. systemd — это принятый стандарт для дистрибутивов Linux, который выполняет создание, проверку, активацию, определение параметров для запуска и готовности системы к работе после запуска ядра. Другими слова systemd является системой инициализации и диспетчером. В управлении systemd существует разные типы модулей, они делятся на отдельные категории в зависимости от их ресурса и назначения которое они несут. Определить тип таких модулей можно по приставке в конце, например, .service — файлы модулей служб, .socket — файлы модулей сокета и т.д.
В свою очередь systemctl является инструментом для управления системой инициализации, с помощью него можно взаимодействовать с systemd и выполнять необходимые операции и команды по его настройке. Он пришел на смену Init.и включает в себя утилиты, библиотеки, демоны и т.д, для контроля и выполнения операций над службами в линуксоидных системах.
Управление службами. Команды
Чтобы проверить какие сервисы сейчас запущены на сервере и узнать их статус, также краткую информацию о их состоянии можно использовать команду:
На выводе команды получим:
UNIT LOAD ACTIVE SUB DESCRIPTION
httpd.service loaded active running The Apache HTTP Server
auditd.service loaded active running Security Auditing Service
crond.service loaded active running Command Scheduler
dovecot.service loaded active running Dovecot IMAP/POP3 email server
dbus.service loaded active running D-Bus System Message Bus
exim.service loaded active running Exim Mail Transport Agent
UNIT — название модуля;
LOAD — указывает загружались ли конфигурация модуля;
ACTIVE — указывает активный ли модуль;
SUB — указывает на состояние метода работы модуля;
DESCRIPTION — краткое описание назначения модуля.
Используя systemctl, можно проверить состояние любой службы systemd. Команда состояния предоставляет информацию о службе, определяет активность службы или сведения о том, почему оно не работает. Для этого используем команду:
systemctl status [service.name]
где [service.name] — название службы.
Systemctl также может использоваться для запуска или остановки служб systemd. Чтобы остановить службу применяется команда:
systemctl stop [service.name]
А чтобы запустить:
systemctl start [service.name]
Если после внесения обновлений вам необходимо перезапустить службу используется команда:
systemctl restart [service.name]
Перезапуск остановит службу и запущенные ее процессы и запустить их заново.
Перезагрузка службы работает путем остановки рабочих процессов, внесение изменений в конфигурации и после заново запускает процессы. Перезагрузка не отключает саму службу. Выполнить перезагрузку можно если система может сделать внесенные обновления без полного перезапуска. Выполняется через команду
systemctl reload [service.name]
- Добавление и удаление служб с автозагрузки
Если необходимо, чтобы служба автоматически запускалась при включении или перезагрузке сервера, это позволяет не запускать каждый раз службы вручную, используется команда:
systemctl enable [service.name]
Также вы можете проверить добавлена ли определенная служба в автозагрузку через команду:
systemctl is-enable [service.name]
Если нужно убрать службу с автозапуска, прописываем команду:
systemctl disable [service.name]
Использование systemd
В этой статье мы рассмотрим систему инициализации Systemd, позволяющую гибко управлять демонами, являющуюся удобным инструментом, облегчающим администрирование операционных систем Linux. Основная цель Systemd — иметь полный контроль над процессами во время их запуска и выполнения. Systemd имеет простую и эффективную логику. Она поддерживает параллельную загрузку служб с заданными зависимостями, имеет собственную систему журналирования событий, имеет встроенные таймеры выполнения задач. Начиная с CentOS7, Debian8, Ubuntu 15.04, Fedora15, система инициализации Systemd установлена по умолчанию.
Как это работает: При запуске сервера запускается ядро, это является первым процессом, он имеет идентификатор «0». После того как процесс инициализировался, запускается процесс init с идентификатором «1». Init выполняет инициализацию системы, которую берет из рабочий директорий. В частности, в каталоге /sbin/init мы можем увидеть линк на /lib/systemd/systemd. Он уже в сою очередь, согласно своим параметрам запускает в фоновом режиме службы (демоны), которые находятся в каталоге /etc/init.d/
Systemd представляет собой описание конфигурации сервисов в виде юнитов, которые имеют следующую структуру каталогов:
/usr/lib/systemd/system/ — расположены юниты, которые созданы из установленных пакетов
/run/systemd/system/ — юниты, которые созданы во время выполнения программного обеспечения (в run-time)
/etc/systemd/system/ — юниты, которые создал администратор сервера. Так же здесь расположены юниты, которые отредактированы вручную.
Оглавление
- Юниты systemd
- Структура юнита systemd
- Редактирование юнитов
- Создание юнитов
- Анализ ошибок с помощью journalctl
- Интерфейс для systemd (опционально)
- Основные команды systemd
- Заключение
1. Юниты systemd.
Прежде всего, нужно разобраться что такое юнит, что означают его статус, и как их фильтровать. Unit — это описание сервиса в текстовом виде, где указаны операции, которые должны быть выполнены до и после запуска службы. Юнит — это описание параметров системы инициализации.
Наиболее часто, управление демонами происходит командами start|stop|reload|status|enable|disable. Для примера, мы можем проверить статус демона как каноничной подсистемы инициализации init (он же System V или SysV):
root@dedicated:~ /etc/init.d/nginx status
Общая команда будет иметь следующий вид:
root@dedicated:~ sudo service nginx status
. или выполнить тоже самое с помощью systemd:
root@dedicated:~ systemctl status nginx.service
Посмотреть список всех запущенных юнитов можно командой:
root@dedicated:~ systemctl
Мы увидим список всех запущенных юнитов, а так же их статус.
UNIT — имя юнита
LOAD — информирует нас о успешной загрузке конфигурации.
ACTIVE — Активный ли юнит.
SUB — более детальная системная информация о юните.
DESCRIPTION — краткое описание.
На скриншотах выше, в колонке UNIT, после префикса, указан тип юнита. Например *.service указывает, что юнит указывает на службу (nginx, apache и т.д.). Существует несколько возможных видов юнитов (socket, device, mount, swap, automount, target, snapshot, timer и другие). На данный момент многие из них нам не пригодятся, потому рассмотрим базовый *.service, на которые стоит обратить внимание. Задача на данный момент — указать путь, а не запутать читателя. Ссылка на руководство по углубленному изучению будет предоставлена в конце статьи.
Отфильтруем только службы:
root@dedicated:~ systemctl list-units --type=service
Отфильтруем неактивные юниты:
root@dedicated:~ systemctl list-units --all --state=inactive
Существуют следующие статусы: active, inactive, running, exited, dead, loaded, not-found, plugged, mounted, waiting, listening.
Посмотреть самую полную информацию, включая юниты, которые система по какой-то причине не загрузила:
root@dedicated:~ systemctl list-units --all
Отобразить список зависимостей определенного юнита
root@dedicated:~ systemctl list-dependencies nginx.service
Используя флаги, одной только командой systemctl вы можете получить представление о системе для анализа ее работы. Так же опытный администратор может отключить необязательные службы с автозагрузки, тем самым выполнив оптимизацию загрузки сервера.
2. Структура юнита systemd
Давайте рассмотрим файл юнита Nginx, и из чего он состоит. На первый взгляд, эта информация может показаться запутанной, но она вполне логична и обязательна для понимания.
root@dedicated:~ systemctl cat nginx.service
[Unit] — Обычно здесь описаны метаданные службы и её взаимодействие с другими службами.
Description — краткое описание демона
Documentation — страница man, где описана работа со службой, в данном случае Nginx
After — Дословно означает «После». Поле указывает, после каких демонов или событий данный юнит будет запущен. На нашем примере, юнит Nginx будет запущен после того, как поднимутся сетевые интерфейсы.
[Service] — Описывает конфигурацию. Применяется только для юнитов служб.
Type — Важный параметр. Описывает, каким образом демон будет запущен. В нашем варианте это forking, но вы можете столкнуться и с другими:
forking — после запуска демон ответвляется (fork), завершая родительский процесс;
simple — при запуске, демон переходит в режим ожидания, в своем первоначальном виде;
one-shot — одноразовое выполнение. Данный тип используется для скриптов, которые должны запуститься, и завершиться после выполнения.
PIDFile — указывает на основной процесс, который отслеживает systemd
ExecStartPre — основной путь и аргументы, с которыми будет запущена команда ДО запуска основного процесса
ExecStart — основной путь и аргументы, с которым будет запущен Nginx
ExecReload — указывает команду для перезапуска службы
ExecStop — команда для остановки службы
TimeoutStopSec — Указывает, что система будет ждать 5 секунд остановки службы, прежде чем остановить её принудительно
[Install] — описывает поведение юнита.
WantedBy — описывает как именно устройство будет включено. multi-user.target означает, что при запуске, в каталоге /etc/systemd/system будет создан каталог multi-user.target.wants, в котором будет создана символическая ссылка на службу. Это параметр зависимости с текущим блоком, когда вы остановите службу, эта ссылка будет удалена.
С доступным перечнем параметров вы можете ознакомится обратившись к руководству:
root@dedicated:~ man systemd.unit
А теперь в двух словах, чем нам может быть полезна эта информация. В зависимости от задач, мы эти юниты можем создавать, редактировать и настраивать их поведение. Мы можем указать порядок загрузки той или иной службы, настраивать зависимости между службами. Например, у нас имеется сервер с критической службой, которая всегда должна быть активна. Мы можем выставить параметр принудительно перезагрузки, если по каким-то причинам она не отвечает. Так же укажем информирование по e-mail об инциденте. В случае если «упал» Apache, он будет автоматически перезагружен без участия администратора. Администратор получит уведомление на e-mail и оказавшись у терминала, приступит к анализу, почему это произошло.
3. Редактирование юнитов
Напрямую юниты не редактируются. Для редактирования существует команда edit:
root@dedicated:~ systemctl edit --full nginx.service
Выше мы говорили про автоматический перезапуск служб. Давайте рассмотрим этот пример. Добавим в секции [Service] два параметра
Restart=on-failure RestartSec=60s
![Добавление параметров в секцию [Service]](https://cdn.freehost.com.ua/systemd6.jpg)
Чтобы изменения вступили в силу, перезапустим конфигурацию:
root@dedicated:~ systemctl daemon-reload
Проверим, что у нас получилось. Узнаем PID процесса:
root@dedicated:~ systemctl status nginx.service | grep PID Main PID: 12567 (nginx)
root@dedicated:~ kill -9 12567
Известной уже командой проверим его статус
root@dedicated:~ systemctl status nginx.service
. ждем 60 секунд. И проверяем снова:
4. Создание юнитов.
Очень часто может понадобится создание юнитов. Например если вы написали свое приложение на Python, и хотите описать его в виде сервиса для управления в systemd. Для примера создадим тестовый юнит test.service.
root@dedicated:~ mcedit /etc/systemd/system/test.service
Добавим в него содержимое:
[Unit] Description=test service [Service] Type=oneshot ExecStart=/bin/echo "Hello World!" RemainAfterExit=yes
Выполним переконфигурацию и запустим наш тестовый юнит
root@dedicated:~ systemctl daemon-reload root@dedicated:~ systemctl start test.service root@dedicated:~ systemctl status test.service
Умение создавать юниты может понадобится не только разработчикам, но и системным администраторам при установке различного программного обеспечения. Рандомно, для примера, обратимся к установке популярного брокера сообщений Apache Kafka. Для управления состоянием кластера и конфигурациями, Kafka использует службу zookiper. В руководстве будет предложено создать для него юнит. Или, например, вы устанавливаете Redmine с популярным web-сервером Puma для Ruby приложений. Для Puma так же нужно будет создать юнит. И так далее.
5. Анализ ошибок с помощью journalctl
Еще одна важная полезность — логи запущенных юнитов. Давайте вспомним первоначальный запуск сервера, когда на мониторе при запуске быстро бежит полотно информации. Иногда там можно увидеть ошибки запуска служб, на которые стоит обратить внимание. Если же вы перезагружаете сервер удаленно, то эту информацию вы не увидите вовсе. После загрузки Linux, мы всегда её можем отобразить для анализа. Хорошим тоном является анализировать логи после каждой перезагрузки сервера.
Для просмотра логов последней загрузки:
root@dedicated:~ journalctl -b
Логи всех загрузок
root@dedicated:~ journalctl
Отобразить список последних загрузок:
root@dedicated:~ journalctl --list-boots
Если мы хотим посмотреть лог загрузки за определенную дату, мы можем это сделать по boot_id, которые отображены в предыдущей команде:
root@dedicated:~ journalctl -b 9e8736b29ad549ab97923baf470382d6
Посмотреть все логи загрузки определённой службы:
root@dedicated:~ journalctl -u nginx
Посмотреть логи загрузки определённой службы в текущей загрузке:
root@dedicated:~ journalctl -b -u nginx
Будет полезна фильтрация логов по уровню ошибок. Всего существует 8 уровней:
0 — EMERG (самая критическая ошибка, служба неработоспособна);
1 — ALERT (требует вмешательства);
2 — CRIT (критическая ошибка);
4 — WARNING (предупреждение);
5 — NOTICE (следует обратить внимание);
6 — INFO (информационное сообщение);
Отобразим все сообщения WARNING по идентификатору «4»:
root@dedicated:~ journalctl -p 4 -b
Посмотреть последние 10 записей:
root@dedicated:~ journalctl -n 10
В реальном времени:
root@dedicated:~ journalctl -f
Для наглядности, предлагаю «помучить» наш Nginx. Для этого убедимся, что служба работоспособна, затем преднамеренно её поломаем, изменив название главного конфигурационного файла и перезапустим Nginx.
root@dedicated:~ systemctl status nginx.service root@dedicated:~ mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf.default root@dedicated:~ systemctl stop nginx.service root@dedicated:~ systemctl start nginx.service
Ожидаемо, мы получим сообщение об ошибке. Без nginx.conf служба не может быть запущена:
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
Обратимся к логам:
root@dedicated:~ journalctl -xe
root@dedicated:~ systemctl status nginx.service
6. Интерфейс для systemd (опционально)
Chkservice — удобная утилита для управления юнитами systemd. В Debian 10 она доступна прямо из репозитория:
root@dedicated:~ apt install chkservice
Если в репозиториях вашего дистрибутива она отсутствует, установку можно выполнить с доступного PPA разработчиков:
root@dedicated:~ add-apt-repository ppa:linuxenko/chkservice root@dedicated:~ apt-get update root@dedicated:~ apt-get install chkservice
root@dedicated:~ chkservice
Управление выполняется следующим образом, стрелками «вверх» и «вниз». Запустить юнит — клавиша «r», остановить — клавиша «s». Будьте осторожны, после нажатия клавиши, сигнал немедленно отправляет команду на выполнения без предупреждений.
7. Основные команды systemd
Запуск, перезапуск, остановка и статус сервисов:
systemctl start name.service systemctl stop name.service systemctl restart name.service systemctl status name.service
Добавить в автозагрузку и удалить с автозагрузки:
systemctl enable name.service systemctl disable name.service
Проверить, находится ли юнит в автозагрузке:
systemctl is-enabled name.service
Запретить запуск сервиса ( при котором «service name-app start» не отработает). И разрешить:
systemctl mask name.service systemctl umask name.service
Отобразить службы, которые не смогли запуститься:
systemctl --state=failed
Отобразить страницу руководства:
systemctl help name.service
Применить конфигурацию после внесения изменений в описание юнита:
systemctl daemon-reload
8. Заключение
Уже много лет не утихают споры, нужен ли systemd как замена init. Доводы двух сторон имеют право на существование, однако они всё дальше уходят от конкретики в дебри философии Linux. Systemd многие популярные дистрибутивы сделали системой инициализации по умолчанию, это уже та причина-минимум, почему стоит её освоить. Фактически она стала стандартом. В рамках одной статьи невозможно сполна раскрыть тему, потому мы старались своими словами и доступно объяснить читателю азы, которые уже можно применить на практике и которые поспособствуют старту к углубленному изучению systemd. Залог стабильной работы сервера — глубокое понимание работы его служб, их взаимодействия и тонкая конфигурация под свои задачи. Для более глубокого изучения, мы рекомендуем прочитать замечательный перевод книги Леннарта Пёттеринга, разработчика systemd.
В дата-центре FREEhost.UA Вы можете арендовать выделенный сервер или виртуальный сервер с OS семейства Linux или FreeBSD. Сервер Вы получаете полностью настроенным и готовым к работе. Если в процессе использования услуги у Вас возникнут вопросы, мы будем рады на них ответить.