Как написать файл модуля systemd для автозагрузки

Обновлено: 03.07.2024

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

Система systemd делает все это проще, очень проще. Если вам нужно что-то, что отслеживает ваше приложение и легко им управляет, systemd — это то, что вам нужно, и это то, что я собираюсь объяснить здесь!

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

Точное расположение зависит от того, почему и как была установлена служба. Если служба установлена менеджером пакетов, обычно она находится в /usr/lib/systemd/system. Для программного обеспечения, которое вы разрабатываете или которое не поддерживает systemd само по себе, вы поместите служебный файл в /usr/local/lib/systemd/system. Пожалуйста, имейте в виду, что некоторые дистрибутивы не поддерживают эту папку в /usr/local. Наконец, если вы хотите настроить существующую службу systemd, вам подойдет файл /etc/systemd/system.

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

Хорошо, пожалуйста, создайте служебный файл в своих документах. Теперь мы готовы рассмотреть, как написать этот файл.
[Примечание: см. отчет о потенциальной ошибке в разделе комментариев к этому сообщению блога]

[ Служба ]
Тип = простой
ExecStart = /usr/bin/python3 /usr/local/bin/penguin-web-app/main. py
Перезапустить = всегда

На самом деле формат файла близок к ini. Я знаю, что это может быть странно, учитывая, что ini-файлы часто встречаются в Windows, но именно так это и работает. Сервисный файл сначала делится на 2 раздела: [Unit] и [Service]. Каждый раздел настраивает определенный аспект systemd: [Unit] содержит элементы, общие для всех файлов модулей systemd, тогда как [Service] предназначен только для конфигурации, специфичной для настройки новой службы.

Затем раздел настраивается с такими свойствами, как Description= или ExecStart=. Значение отделяется от имени свойства знаком равенства = без пробела.

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

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

Свойства служб Systemd

Давайте сначала сосредоточимся на свойствах в [Unit]:

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

WantedBy= позволяет сказать systemd: когда эта штука запускается, запускается и я. Как правило, вы указываете имя цели. Примеры общих целей:

multi-user.target: когда сервер в порядке и готов запускать приложения командной строки
graphical.target: когда GNOME или KDE готовы
network-up.target: когда сервер правильно подключен к сети

Хорошо, для начала этих свойств [Unit] достаточно. Теперь давайте посмотрим на [Сервис].

Type= помогает systemd узнать, запущена ли служба. Вот распространенные типы:

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

ExecStart=, вероятно, наиболее важен для службы: он указывает, какое приложение запускать при запуске службы. Как вы можете видеть в сервисе Penguin, я сразу использовал /usr/bin/python3, а не python3. Это связано с тем, что документация systemd явно рекомендует использовать абсолютные пути, чтобы избежать каких-либо неожиданностей.

Но это также и по другой причине. Система управления другими службами, как правило, основана на сценариях Shell. Однако systemd по соображениям производительности не запускает оболочку по умолчанию. Таким образом, вы не можете напрямую указать команду оболочки в ExecStart=. Однако вы все равно можете использовать сценарий оболочки, выполнив:

Не так уж и сложно, верно? Обратите внимание, что если вам нужно запустить какой-либо процесс, чтобы сигнализировать о корректной остановке службы, существует ExecStop=, а также ExecReload= для перезагрузки служб.

Restart= позволяет явно указать, когда следует перезапустить службу. Это одна из важных функций systemd: она гарантирует, что ваш сервис будет работать столько, сколько вы пожелаете, поэтому уделите этому параметру особое внимание.

WorkingDirectory= может указать рабочий каталог при запуске вашего приложения. Значение должно быть абсолютным путем к каталогу. Рабочий каталог используется, когда вы используете относительные пути в коде вашего приложения. Для нашего сервиса пингвинов это может быть:

Тогда важна безопасность, поэтому обычно не следует запускать службу с привилегиями root. User= и Group= позволяют вам установить имя пользователя или группы или UID/GID, под которым будет запускаться ваше приложение. Например:

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

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

Синтаксис этого файла прост: вы вводите имя переменной среды, знак равенства = и затем ее значение. Затем вы помещаете абсолютный путь к файлу среды в свойство EnvironmentFile.

И файл /etc/penguin-web-app/environment содержит:

Тогда наше веб-приложение penguins получит доступ к переменной среды LISTEN_PORT и будет прослушивать ожидаемый порт.

Сохраните и запустите только что созданную службу Systemd

Итак, если вы последовали моему совету, вы отредактировали свой служебный файл в своем домашнем каталоге. Когда вы будете удовлетворены, скопируйте этот файл в /usr/local/lib/systemd/system, если ваш дистрибутив поддерживает этот путь. Имя вашего служебного файла будет его служебным именем. Это имя файла должно заканчиваться на .service. Например, для нашего сервера пингвинов это будет penguin-web-app.service.

Затем вам нужно сообщить systemd, что вы добавили новую службу, поэтому вам нужно ввести следующую команду:

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

Теперь время запустить службу:

Если происходит сбой с ошибкой "Блок не найден", такой как эта:

$ sudo systemctl start penguin-web-app.service
Не удалось запустить penguin-web-app.service: устройство не найдено.

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

Если вы настроили свой сервис с помощью WantedBy= и хотите, чтобы ваш сервис запускался автоматически, вы должны включить его с помощью этой команды:

Преимущество сервиса в том, что он работает в фоновом режиме. Проблема: как узнать, работает ли он правильно и работает ли он, если он работает в фоновом режиме? Не волнуйтесь, команда systemd тоже подумала об этом и предоставила команду, чтобы увидеть, правильно ли она работает, сколько времени и т. д.:

Заключение

Поздравляем! Теперь вы можете управлять своими приложениями, не заботясь о ручном перезапуске каждый раз. Теперь я рекомендую вам прочитать другую нашу статью о журналах systemd: Master journalctl: понимание журналов systemd. Благодаря этому вы сможете использовать мощную систему ведения журналов в своем новом сервисе и создавать более надежные серверы!

Об авторе

В эфире

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

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

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

Предпосылки

Для выполнения этого руководства вам потребуется:

Сервер под управлением CentOS 8, включая пользователя без полномочий root с привилегиями sudo. Чтобы настроить все это, включая брандмауэр, вы можете создать дроплет DigitalOcean под управлением CentOS 8, а затем следовать нашему Руководству по начальной настройке сервера.

Знакомство с демоном управления службами

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

init — это первый процесс, который запускается в системе Linux после загрузки машины и загрузки ядра в память. Помимо прочего, он решает, как должен загружаться пользовательский процесс или системная служба, в каком порядке и должны ли они запускаться автоматически.

По мере развития Linux менялось и поведение демона инициализации. Первоначально Linux начинался с инициализации System V, той же самой, которая использовалась в Unix. С тех пор в Linux был реализован демон инициализации Upstart (создан Ubuntu), а теперь демон инициализации systemd (впервые реализован в Fedora).

Большинство современных дистрибутивов Linux постепенно отходят от System V и в настоящее время используют systemd. Инициализация старого стиля (если используется) сохраняется только для обратной совместимости. FreeBSD, разновидность UNIX, использует другую реализацию System V, известную как BSD init.

В этой статье мы рассмотрим systemd, так как это самый последний и распространенный диспетчер служб, который сегодня используется в дистрибутивах Linux. Тем не менее, мы также будем говорить о System V и Upstart, когда это будет необходимо, и посмотрим, как оттуда развился systemd. Чтобы дать вам представление:

System V — старейшая система инициализации, использовавшаяся в
Debian 6 и более ранние версии
Ubuntu 9.04 и более ранние версии
CentOS 5 и более ранние версии
Upstart появился после System V и использовался в
От Ubuntu 9.10 до Ubuntu 14.10, включая Ubuntu 14.04
ЦентрОС 6
systemd — новейший менеджер служб Linux, используемый в
Debian 7 и выше
Ubuntu 15.04 и выше
CentOS 7 и выше

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

Уровни запуска

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

Некоторые службы могут работать на одном или нескольких уровнях выполнения, но не на других. Уровни запуска обозначаются значением от 0 до 6. В следующем списке показано, что означает каждый из этих уровней:

Уровень запуска 0: завершение работы системы
Уровень запуска 1: однопользовательский, аварийный режим
Уровни запуска 2, 3, 4: многопользовательский, текстовый режим с поддержкой сети
Уровень выполнения 5: многопользовательский, сетевой, графический режим.
Уровень выполнения 6: перезагрузка системы

Уровни выполнения 2, 3 и 4 различаются в зависимости от дистрибутива. Например, некоторые дистрибутивы Linux не реализуют уровень запуска 4, в то время как другие поддерживают. Некоторые дистрибутивы имеют четкое различие между этими тремя уровнями. Как правило, уровни запуска 2, 3 или 4 означают состояние, при котором Linux загружается в многопользовательском текстовом режиме с поддержкой сети.

Когда вы включаете автозапуск службы, Linux фактически добавляет ее на уровень выполнения. В System V, например, ОС запускается с определенного уровня выполнения; и, когда он запустится, он попытается запустить все службы, связанные с этим уровнем выполнения. В systemd уровень запуска стал целевым, и когда служба автоматически запускается, она добавляется в целевую. Мы обсудим цели позже в этой статье.

Знакомство с демоном инициализации System V

System V использует файл inittab, который позже были сохранены методами инициализации для обратной совместимости. Давайте рассмотрим последовательность запуска System V:

Демон инициализации создается из двоичного файла /sbin/init
Первый файл, который читает демон инициализации, это /etc/inittab
Одна из записей в этом файле определяет уровень выполнения, с которого должна загружаться машина. Например, если значение для уровня выполнения указано как 3, Linux будет загружаться в многопользовательском текстовом режиме с включенной сетью. (Этот уровень выполнения называется уровнем запуска по умолчанию)
Затем демон инициализации просматривает файл /etc/inittab и читает, какие сценарии инициализации необходимо запустить для данного уровня запуска.

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

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

Когда процесс или служба, например MySQL Server, запускается под System V, его двоичный программный файл должен загружаться в память.В зависимости от того, как настроена служба, эта программа может непрерывно выполняться в фоновом режиме (и принимать клиентские подключения). Работа по запуску, остановке или перезагрузке этого двоичного приложения выполняется сценарием инициализации службы. Он называется сценарием инициализации, поскольку инициализирует службу.

В System V сценарий инициализации представляет собой сценарий оболочки. Их также называют скриптами rc (команда запуска). Скрипты находятся в каталоге /etc/init.d. Эти скрипты имеют символические ссылки на каталоги /etc/rc. В каталоге /etc есть несколько каталогов rc, имя каждого из которых имеет номер. Цифры обозначают разные уровни выполнения. Итак, у нас есть /etc/rc0.d, /etc/rc1.d, /etc/rc2.d и так далее.

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

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

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

Чтобы проверить статус (работает или остановлен), выполните эту команду

Представляем демон Upstart

Поскольку сериализованный способ загрузки заданий и служб стал более трудоемким и сложным с помощью System V init , был представлен демон Upstart для более быстрой загрузки ОС, изящной очистки аварийных служб и предсказуемой зависимости между системными службами.

Инициализация Upstart была лучше, чем инициализация System V по нескольким причинам:

Для загрузки служб и управления ими не использовались тайные сценарии оболочки. Вместо этого он использует простые файлы конфигурации, которые легко понять и изменить.
Службы не загружались последовательно, как System V, что сокращает время загрузки системы.
Использовалась гибкая система событий для настройки обработки служб в различных состояниях.
У Upstart были лучшие способы обработки того, как аварийный сервис должен восстановиться.
Не было необходимости хранить несколько избыточных символических ссылок, указывающих на один и тот же скрипт

Для простоты Upstart обратно совместим с System V. Скрипт /etc/init.d/rc по-прежнему работает для управления собственными службами System V. Его основное отличие заключается в том, что он позволяет связать несколько событий со службой. Эта основанная на событиях архитектура позволила Upstart быть гибким менеджером услуг. С Upstart каждое событие может запустить сценарий оболочки, который позаботится об этом событии. Эти события включали:

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

При запуске Upstart запустит все сценарии инициализации System V в обычном режиме. Затем он просматривает каталог /etc/init и выполняет команды оболочки в каждом файле конфигурации службы. Помимо прочего, эти файлы контролировали поведение службы при запуске.

Файлы имеют стиль именования service_name .conf , и они содержат обычный текст с различными разделами, называемыми строфами. Каждая строфа описывает отдельный аспект службы и ее поведение. Чтобы служба запускалась автоматически после сбоя или перезагрузки, вы можете добавить команду respawn в файлы конфигурации службы, как показано ниже для службы cron.

Знакомство с демоном systemd

Последним демоном инициализации Linux является systemd. На самом деле это больше, чем демон инициализации: systemd — это фреймворк, который включает в себя многие компоненты современной системы Linux.

Одной из его функций является работа в качестве системного и сервисного менеджера для Linux. В этом качестве systemd управляет поведением службы в случае сбоя или перезагрузки машины. Вы можете прочитать о systemctl в systemd здесь.

systemd обратно совместим с командами и сценариями инициализации System V. Это означает, что любая служба System V также будет работать под управлением systemd. Это возможно, потому что большинство административных команд Upstart и System V были изменены для работы в systemd.

Файлы конфигурации systemd: юнит-файлы

В основе systemd лежат юнит-файлы. Каждый модульный файл представляет определенный системный ресурс. Информация о ресурсе хранится в юнит-файле. Файлы служебных модулей — это простые текстовые файлы (например, файлы Upstart .conf) с декларативным синтаксисом. Это упрощает понимание и изменение файлов.

Основное различие между systemd и двумя другими методами инициализации заключается в том, что systemd отвечает за инициализацию сервисных демонов и других типов ресурсов, таких как пути операционной системы устройства, точки монтирования, сокеты и т. д. Стиль именования файла модуля это service_name.unit_type . Итак, вы увидите такие файлы, как dbus.service , sshd.socket или home.mount .

Структура каталогов

В системах на основе Red Hat, таких как CentOS, файлы модулей расположены в двух местах. Основное расположение — /lib/systemd/system/.Пользовательские файлы модулей или существующие файлы модулей, измененные системными администраторами, будут находиться в /etc/systemd/system .

Если юнит-файл с одинаковым именем существует в обоих местах, systemd будет использовать тот, который находится в каталоге /etc. Предположим, служба включена для запуска во время загрузки или любого другого целевого уровня/уровня запуска. В этом случае для этого файла сервисного модуля будет создана символическая ссылка в соответствующих каталогах в /etc/systemd/system. Файлы модулей в /etc/systemd/system на самом деле являются символическими ссылками на файлы с тем же именем в /lib/systemd/system .

Последовательность инициализации systemd: целевые объекты

Особым типом файла модуля является целевой модуль.

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

У каждой цели есть имя, а не номер. Например, у нас есть multi-user.target вместо runlevel 3 или reboot.target вместо runlevel 6. Когда сервер Linux загружается, скажем, с multi-user.target , он, по сути, переводит сервер на уровень выполнения 2, 3 или 4, то есть в многопользовательский текстовый режим с включенной сетью.

Разница в том, как он доводит сервер до этой стадии. В отличие от System V, systemd не запускает службы последовательно. Попутно он может проверять наличие других сервисов или ресурсов и определять порядок их загрузки. Это позволяет службам загружаться параллельно.

Еще одно различие между целевыми модулями и уровнями выполнения заключается в том, что в System V система Linux может существовать только в одном уровне выполнения. Вы можете изменить уровень выполнения, но система будет существовать только на этом новом уровне выполнения. С помощью systemd целевые единицы могут быть инклюзивными, что означает, что когда целевая единица активируется, она может обеспечить загрузку других целевых единиц как ее часть.

Например, в системе Linux, которая загружается с графическим пользовательским интерфейсом, будет активирован graphical.target, что, в свою очередь, автоматически обеспечит загрузку и активацию multi-user.target. В терминах System V это равносильно одновременной активации уровней выполнения 3 и 5.

В таблице ниже сравниваются уровни запуска и цели:

Уровень запуска (System V init)	Целевые модули (Systemd)
уровень запуска 0	poweroff.target
уровень запуска 1	resuce.target
уровень запуска 2, 3, 4	multi-user.target
уровень запуска 5	graphical.target
уровень запуска 6	reboot.target

systemd default.target

systemd default.target эквивалентен уровню выполнения System V по умолчанию.

В System V уровень выполнения по умолчанию определен в файле inittab. В systemd этот файл заменяется на default.target. Файл целевого модуля по умолчанию находится в каталоге /etc/systemd/system. Это символическая ссылка на один из целевых файлов модулей в /lib/systemd/system.

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

Файл inittab в System V также указывает, из какого каталога Linux будет выполнять свои сценарии инициализации: это может быть любой из каталогов rcn.d. В systemd целевая единица по умолчанию определяет, какие единицы ресурсов будут загружены во время загрузки.

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

Зависимости systemd: хочет и требует

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

Как упоминалось ранее, Upstart обеспечивает параллельную загрузку служб с помощью файлов конфигурации. В System V служба могла запускаться на определенном уровне выполнения, но ее также можно было заставить ждать, пока не станет доступна другая служба или ресурс. Аналогичным образом можно заставить службы systemd загружаться в одну или несколько целей или ждать, пока другая служба или ресурс не станут активными.

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

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

Практический пример: понимание последовательности запуска systemd

Чтобы понять поведение запуска службы в systemd, мы используем каплю CentOS 8.3. Мы будем следовать по кроличьей тропе .target насколько это возможно. Последовательность запуска systemd следует длинной цепочке зависимостей.

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

Вывод выглядит следующим образом:

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

многопользовательская.цель.хочет

Далее запустим следующую команду, чтобы проверить все службы, которые нужны файлу multi-user.target:

Это должно показать список файлов символических ссылок, указывающих на фактические файлы модулей в /usr/lib/systemd/system/:

Помимо multi-user.target, существуют другие типы целей, например system-update.target или basic.target. Чтобы увидеть, от каких целей зависит многопользовательская цель, выполните следующую команду:

Вывод показывает:

базовая.цель

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

Оказалось, что для basic.target требуется sysinit.target:

Ему также нужны несколько целей:

Команда вернет следующее:

Двигаясь рекурсивно, вы можете увидеть, потребует ли sysinit.target запуска каких-либо других целей:

Ничего не будет. Однако для sysinit.target будут нужны и другие цели:

Появится такой вывод:

Изучение файла модуля systemd

Сделав еще один шаг, давайте заглянем в файл сервисного модуля, тот, что для sshd:

Это выглядит так:

Вы можете видеть, что файл сервисной единицы чист и понятен.

Первой важной частью является предложение After в разделе [Unit]. Это говорит о том, что служба sshd должна загружаться после загрузки network.target и sshd-keygen.target.

В разделе [Установить] показано, что служба нужна multi-user.target. Это означает, что multi-user.target загрузит демон sshd, но не выключится и не выйдет из строя, если во время загрузки произойдет сбой sshd.

Поскольку multi-user.target является целью по умолчанию, демон sshd должен запускаться во время загрузки. В секции [Service] параметр Restart имеет значение on-failure. Этот параметр позволяет перезапускать демон sshd в случае сбоя или некорректного выхода.

Заключение

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

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

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

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

Серия руководств: Как настроить службу Linux для автоматического запуска после сбоя или перезагрузки

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

Systemd — это система инициализации и системный менеджер, которая в последнее время приобрела большую популярность. Более того, он становится новым стандартом для Linux-машин. Хотя есть обоснованные сомнения относительно того, является ли systemd улучшением по сравнению с традиционными системами инициализации SysV, большинство дистрибутивов уже перешли на systemd или планируют это сделать.

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

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

Поскольку systemd широко используется в Linux-системах, на знакомство с ним стоит потратить время.Кроме того, понимание systemd значительно облегчит администрирование сервера на вашем рабочем столе. В то же время изучение и использование инструментов и демонов systemd поможет вам лучше оценить мощность, гибкость и возможности, предоставляемые ИТ.

Systemctl и Systemd

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

Вы также должны принять во внимание, что, несмотря на то, что система стала стандартной системой инициализации для многих дистрибутивов Linux, она не реализована во всех дистрибутивах. По ходу выполнения этого руководства, если на вашем терминале отображается ошибка bash: systemctl не установлена (bash: systemctl не установлена), то, возможно, у вас другая инициализация системы, установленной на вашем компьютере.

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

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

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

Для задач управления службами целевой единицей является единица службы, в которой есть файлы единиц с суффиксом «.service». Однако для большинства команд управления службами вы можете опустить суффикс «.service». Кроме того, systemd достаточно умен, чтобы знать, что вы, вероятно, захотите работать с сервисом при использовании команд управления сервисом.

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

Во-первых, чтобы запустить системную службу, следуя инструкциям в файле модуля, используйте команду start. Если вы работаете как пользователь без полномочий root, вам придется использовать sudo. Причина этого в том, что команда, которую вы выполняете, изменит состояние операционной системы:

В этой статье описывается, как автоматически запускать приложение во время или после загрузки компьютеров Apalis, Colibri и Verdin на модулях, работающих под управлением Embedded Linux.

В TorizonCore приложения упакованы в контейнеры. Контейнеры запускаются подсистемой контейнеров, в нашем случае это Docker.

Docker уже настроен на автозапуск, и для запуска ваших приложений при загрузке в TorizonCore вы должны описать, какие контейнеры использовать и как их вызывать. Пожалуйста, ознакомьтесь с нашими материалами о шагах по автоматическому запуску контейнера с помощью TorizonCore в разделе «Запуск и управление контейнерами Docker в Torizon».

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

Системный

Начиная с версии 2.x нашего Linux BSP мы используем systemd в качестве диспетчера инициализации и служб.

Systemd — это системный и сервисный менеджер для Linux, который также может заменить традиционную систему инициализации SysV. Вы можете прочитать его руководство здесь.

Конфигурация модуля – это файл, имя которого заканчивается на .service. В нем содержится информация о процессе, который контролируется и контролируется systemd. Служебные файлы можно найти в /etc/systemd/system/, а для дистрибутива — в /lib/systemd/system/ .

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

Общие элементы конфигурации настраиваются в общих разделах [Unit] и [Install].

Параметры конфигурации конкретной службы настраиваются в разделе [Сервис].

Файлы службы должны включать раздел [Service], который содержит информацию о службе и контролируемом ею процессе.

Для получения дополнительной информации о возможных опциях раздела [Сервис] обратитесь к документации.

Процедура

Создайте файл конфигурации объекта с расширением .service

Скопируйте файл конфигурации модуля в /etc/systemd/system и используйте инструмент systemctl для включения и запуска службы.

Использование команды systemctl

Исходя из документации SystemD, вам необходимо перезагрузить конфигурацию systemd после добавления или изменения любых юнит-файлов:

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

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

Вот пример файла конфигурации устройства для автоматического запуска (гипотетического) приложения mydatalogger при запуске:

Оболочки

/etc/профиль

Каждый раз, когда запускается оболочка входа в систему, выполняется сценарий /etc/profile и все сценарии в /etc/profile.d.

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

/etc/profile загружается при входе в систему: он настраивает среду при входе в систему и настройки приложения, получая любой доступный для чтения файл в /etc/profile.d/ .

Использование /etc/profile хорошо подходит для настройки среды или выполнения небольших задач.

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

Удалите файл в /etc/profile.d или дополнения к /etc/profile, чтобы отменить автоматическое выполнение.

Процедура

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

Помните, что сценарий оболочки должен иметь расширение *.sh.

Ниже приведен пример файла сценария для удаления записей резервной копии:

Графический

Настольный компьютер Weston

В более поздней версии Toradex Linux BSP 5 используется графический компоновщик Weston/Wayland вместо X11, который использовался до BSP 3.0.

Обратите внимание, что Wayland — это протокол, а Weston — графический компоновщик, реализующий протокол Wayland. Подробнее об этом можно прочитать на странице Wayland.

Любое графическое приложение, разработанное для X11, также должно работать, поскольку компоновщик Weston настроен на работу с режимом совместимости XWayleand, что позволяет использовать клиенты X11.

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

Пример автоматического запуска графического приложения wayland при загрузке представлен ниже.

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

Уэстон будет использовать XDG_RUNTIME_DIR для контекста окна.

Также рекомендуется соответствующим образом экспортировать переменную DISPLAY. См. ниже:

С сервисом и скриптом ваше приложение Wayland будет автоматически запускаться при загрузке.

Проект Yocto/OpenEmbedded

Мы подготовили сценарии для автоматического запуска вашего приложения в Wayland/Weston при запуске непосредственно из сборки Yocto Project/OpenEmbedded. Это называется wayland-app-launch, а также то, как мы автоматически запускаем демонстрации Qt на эталонном мультимедийном изображении. Ознакомьтесь с приведенными ссылками, которые содержат примеры того, как вы можете интегрировать это в OE.

X11 для рабочего стола

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

С angstrom-lxde-image вы получите следующие возможности. Другие среды рабочего стола предоставляют аналогичные средства.

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

Этого можно добиться двумя способами:

Специфический для lxsession способ, которым анализируются записи в файлах /etc/xdg/lxsession/LXDE/autostart и ~/.config/lxsession/LXDE/autostart.

Общий способ, поддерживаемый многими диспетчерами сеансов. Файлы в папках /etc/xdg/autostart/ и ~/.config/autostart/, оканчивающиеся на .desktop, анализируются и, если применимо, запускается описанное в них приложение.

Дополнительную информацию можно найти в документации по LXSession.

Файл автозапуска LXSession

Чтобы использовать первый вариант, вам нужно отредактировать файл /etc/xdg/lxsession/LXDE/autostart или ~/.config/lxsession/LXDE/autostart.

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

Если вы хотите, чтобы ваше приложение перезапускалось в случае аварийного завершения работы, поставьте перед именем приложения символ @. Как, например, lxterminal с @lxterminal в /etc/xdg/lxsession/LXDE/autostart:

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

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

Файлы .desktop

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

Дополнительную информацию об этом можно найти в документации к файлу .desktop. Примечание. В /usr/share/applications/ уже есть несколько файлов .desktop, которые можно скопировать в папку автозапуска.

Например, если вы хотите автоматически запускать lxterminal при запуске, вы можете сделать следующее: 1. Создайте terminal.desktop в /etc/xdg/autostart/ . Добавьте несколько ключевых записей, таких как:

[Desktop Entry] — должна быть первой строкой каждого файла рабочего стола и заголовком раздела для идентификации блока пар ключ-значение, связанного с рабочим столом. Необходимо, чтобы рабочий стол правильно распознал файл.
Имя приложения. (Имя группы Desktop Entry — должно быть уникальным в системе)
Тип приложения. (Возможные значения: «Приложение», «Ссылка» или «Каталог».)
Имя исполняемого файла приложения плюс необязательные аргументы.
Терминал (описывает, должно ли приложение работать в терминале.)

Пример содержимого файла .desktop с записями должен быть следующим:

После редактирования сохраните рабочий стол.

Примечание. Графический файловый менеджер будет отображать файлы .desktop не с их именами, а со значением ключа «Имя». например в приведенном выше примере "LXTerminal".

Чтобы отключить автоматический запуск приложения, просто удалите соответствующий файл *.desktop из /etc/xdg/autostart/ и/или .config/autostart/ или добавьте ключ NotShowIn=LXDE; в файл рабочего стола.

В качестве альтернативы используйте графический интерфейс «Меню LXDE»/Настройки/«Настройки сеанса рабочего стола» и снимите флажок «Включено».

X11 с одним пользовательским приложением

Если ваш вариант использования требует запуска X11, вероятно, также потребуется запустить некоторые задачи настройки, такие как сопоставление клавиатуры, калибровка сенсорного экрана, а затем запустить единственное пользовательское приложение. В этом случае вы можете использовать схему, подобную той, что используется в angstrom-qt5-x11-image и qt4e-demo-image.

Скрипт, запущенный Systemd

В qt4e-demo-image и angstrom-qt5-x11-image (до версии 2.8b2) используется служба systemd и сценарий домашнего приготовления. Сценарий запускает X-сервер, а затем пользовательское приложение. Интеграция любых задач установки между запуском X11 и запуском пользовательского приложения в сценарий приводит к множеству проблем, поскольку иногда это останавливает X-сервер и т. д.

Однако для простой системы этого может быть достаточно.

Чтобы запустить приложение X11 вместо демонстрационного приложения, измените сценарий соответствующим образом.

Использование nodm, xinit и пользовательского скрипта

В образе angstrom-qt5-x11 (начиная с версии 2.8b2) для запуска X11 используется простой менеджер отображения nodm из OpenEmbedded. При этом используются данные конфигурации в /etc/X11 , например. Xsession.d, например. для запуска сенсорного калибратора. В качестве последнего шага он ищет скрипт x-window-manager и получает его.

Чтобы запустить приложение X11, переопределите следующие две переменные в рецепте x-window-simple-app, чтобы установить начальный рабочий каталог и указать приложение:

Invicti Web Application Security Scanner — единственное решение, обеспечивающее автоматическую проверку уязвимостей с помощью Proof-Based Scanning™.

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

Обеспечьте безопасность приложений правильно! Обнаружение, защита, мониторинг, ускорение и многое другое…

Не знаете, как управлять службами в фоновом режиме или при загрузке?

Изменен механизм управления и запуска процессов при загрузке. До RHEL/CentOS 6.x вы должны были создать сценарий в /etc/init.d/ и включить его с помощью chkconfig, но в RHEL 7 все по-другому.

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

Что такое systemd?

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

Держу пари, вы сразу это заметили. первый процесс в списке был запущен от имени пользователя root и имеет pid 1.

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

Проще говоря, systemd — это «материнский» процесс, который запускает, управляет и завершает другие процессы в системе, помимо предоставления информации об их ведении журналов, состояниях файловой системы и т. д.

Однако примечание к названию. Имя действительно systemd, а не System D или что-то еще. Буква «d» означает «демон», стандартный процесс Linux, который работает (прячется?) в фоновом режиме и не привязан ни к какому терминальному сеансу.

Почему RHEL перешел на systemd?

Как мы уже говорили, systemd — это менеджер системы и процессов, который в RHEL 7 заменяет известную программу Upstart. Почему RHEL принял такое решение? Что ж, для этого есть очень веские причины, так что давайте кратко рассмотрим.

Инициализация параллельной службы

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

Динамическое (горячее) управление услугами

Если вы заметили, что USB-накопители необходимо явно монтировать в более ранних системах Fedora, в то время как они автоматически открывались в Ubuntu и подобных дистрибутивах, причина в systemd . Он способен обнаруживать изменения в оборудовании в режиме реального времени и при необходимости завершать/запускать службы. Кто-то может возразить, что в этом нет необходимости, но для многих все, что снижает когнитивную нагрузку, приветствуется.

Отложенный запуск службы

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

Ускоренная коммуникация процессов

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

Автоматический перезапуск

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

В любом случае, systemd облегчает жизнь системному администратору.

systemd в RHEL7 — какие изменения для системных администраторов?

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

Ограниченная поддержка уровня запуска

Система довольно плохо распознает и поддерживает уровни выполнения. Поддерживаются не все уровни запуска, а для некоторых целей их может вообще не быть. В таких случаях systemd возвращает «N» в качестве ответа на команды уровня запуска, означая, что у него нет соответствующего уровня запуска для этой цели. В общем, Red Hat советует нам не использовать (!) команды уровня выполнения.

Нет пользовательских команд

Это будет больно. Одним из больших плюсов SysV была возможность определять пользовательские команды для улучшения функциональности управления процессами. С systemd такой опции нет, и вы застряли с start , stop , status , restart и т. д.

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

systemd (конечно же) отслеживает запущенные процессы и сохраняет их PID. Проблема, однако, в том, что systemd не может работать с процессами, запущенными не им. Кроме того, пользователь не может взаимодействовать с процессом, запущенным systemd. Все выходные данные направляются в /dev/null , что фактически лишает вас надежд на сбор выходных данных.

Без контекста

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

Если этот список ограничений заставляет вас плакать, опять же, вы не одиноки. systemd был поляризующей силой в мире Linux, и поиск в Google «systemd отстой» найдет много материала для чтения. 😉

Как автоматически запускать службу при отключении?

Вот довольно распространенный пример использования при развертывании. Нам нужно демонизировать программу на языке, который не имеет длительных процессов: PHP! Предположим, я пишу PHP-скрипт для обработки входящих подключений через веб-сокет (в конце концов, мы создали приложение для чата!), и этот скрипт размещен в /home/ankush/chat_server/index.php .

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

Все службы systemd находятся в /etc/systemd/system, поэтому давайте создадим там файл для описания сценария нашего веб-сервера. Предположим, вы вошли в систему как пользователь root.

и затем необходимо следующее.

Сохраните файл, и следующим шагом будет перезагрузка демона systemd

и для запуска службы, которую мы только что создали:

Если вы не видите ошибок, значит все!

Давайте также быстро рассмотрим, что означают различные директивы в файле:

Часть [Unit] определяет новую единицу обслуживания для systemd. На языке systemd все сервисы называются сервисными единицами.
Директива After (как и ожидалось) указывает systemd запускать эту службу только после запуска сетевых служб (иначе, кто будет выполнять низкоуровневую обработку соединений через сокеты?!).
Type=simple сообщает systemd, что этот сервис не должен разветвляться. Другими словами, в любой момент времени будет работать только один экземпляр.
User=ankush означает, что эта служба будет работать от имени пользователя «ankush». Мы могли бы изменить это на «root», но это крайне не рекомендуется с точки зрения безопасности.
Вы можете сказать, что ExecStart — это фактическая команда для запуска.
Restart=on-abort означает, что служба должна быть перезапущена после прерывания. В PHP длительные процессы приводят к утечке памяти и в конечном итоге взрываются, поэтому это необходимо.
Директива WantedBy= сообщает systemd, частью какой цели (подумайте о группах) является эта служба. В результате внутри этой цели создаются символические ссылки, указывающие на службу.

Как правило, этого достаточно для запуска фоновых процессов с использованием systemd в RHEL 7.

Дополнительные параметры для логики перезапуска

В приведенном выше примере я настроил Restart=on-abort, но это не единственный вариант. Есть больше и выберите в зависимости от требований.

при сбое — будет перезапущен при нечистом коде выхода или сигнале
всегда — перезапускать при обнаружении неработающего, чистого или нечистого сигнала
on-abnormal – нечистый сигнал, сторожевой таймер или тайм-аут
при успешном выполнении — только если он был остановлен чистым сигналом или кодом выхода

Настройка службы для запуска при загрузке

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

Перейдите в /etc/systemd/system и выполните приведенную ниже команду enable (не забудьте изменить имя файла .service на то, которое у вас есть)

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

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

Это было легко! Не так ли?

Помогите! Я вложил огромные средства в Upstart. 🙁

Я понимаю, что вы мне доверяете, ваш случай скорее норма, чем исключение. RHEL использует Upstart так долго, что это переключение кажется почти предательством. Но эй, системы продолжают меняться, и мы не должны ссориться по пустякам. Red Hat понимает, что многие люди застряли на старых версиях, и создала руководство по миграции, к которому вам обязательно следует обратиться.

Спасением во всем этом является то, что systemd совместим со сценариями инициализации SysV, поэтому по большей части вам нужно будет просто переместить файлы и запустить те же службы.

Хотите узнать больше об администрировании Linux и устранении неполадок? Ознакомьтесь с этим онлайн-курсом.

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