Как сделать службу linux

Добавил пользователь Евгений Кузнецов
Обновлено: 04.10.2024

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

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

Обратите внимание, что хотя система systemd стала системой инициализации по умолчанию для многих дистрибутивов Linux, она не используется повсеместно во всех дистрибутивах. По мере изучения этого руководства, если ваш терминал выводит ошибку bash: systemctl is not installed , скорее всего, на вашей машине установлена другая система инициализации.

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

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

Для задач по управлению службами целевым модулем будут модули службы, которые имеют файлы модулей с суффиксом .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 вы можете видеть следующий вывод:

Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий.

Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду is-active :

Чтобы увидеть, включен ли модуль, можно использовать команду is-enabled :

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

Обзор состояния системы

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

Список текущих модулей

Чтобы увидеть список всех активных модулей, о которых знает systemd , можно использовать команду list-units :

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

Вывод содержит следующие столбцы:

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 необязательно считывала все определения модуля в этом виде, она представляет информацию только о самих файлах. Вывод содержит два столбца: файл модуля и состояние.

Состояние будет, как правило, enabled , disabled , static или masked . В этом контексте static обозначает, что файл модуля не содержит раздел install , который используется для включения модуля. Эти модули как таковые не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость другого модуля и не должен работать самостоятельно.

Мы рассмотрим сразу же, что означает masked .

Управление модулями

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

Отображение файла модуля

Чтобы отобразить файл модуля, который система systemd загрузила в систему, можно использовать команду cat (она была добавлена в версию systemd 209). Например, чтобы увидеть файл модуля демона-планировщика atd , можно ввести следующее:

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

Отображение зависимостей

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

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

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

Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флаг --reverse . Другие полезные флаги --before и --after могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно, перед ними и после.

Проверка свойств модуля

Чтобы увидеть свойства более низкого уровня модуля, можно использовать команду show . При этом будет выведен список свойств, заданных для указанного модуля с помощью формата key=value :

Если вы хотите отобразить одно свойство, можно передать флаг -p с именем свойства. Например, чтобы увидеть конфликты, которые есть у модуля sshd.service , можно ввести следующее:

Маскировка и снятие маскировки модулей

В разделе управления службами мы узнали, как остановить или отключить службу, но systemd также имеет возможность отметить модуль как полностью незапускаемый, автоматически или вручную, связав его с /dev/null . Это называется маскировкой модуля, и она возможна с помощью команды mask :

Это не позволит запустить службу Nginx автоматически или вручную, пока она замаскирована.

Если вы проверите list-unit-files , вы увидите, что служба теперь указана как замаскированная:

Чтобы снять маскировку модуля и сделать его доступным для использования снова, используйте команду 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 имеет цель по умолчанию, которую он использует при загрузке системы. Удовлетворение каскада зависимостей от этой одной цели приведет систему в желаемое состояние. Чтобы найти цель по умолчанию для вашей системы, введите:

Если вы хотите задать другую цель по умолчанию, можно использовать 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 соответственно). Знакомство с этими другими инструментами и демонами упростит задачу управления.

Systemd – это программное приложение, которое предоставляет набор системных компонентов для операционных систем Linux.

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

Она всегда работает с pid 1.

Она также помогает управлять системой и сервисом приложений в нашей операционной системе Linux.

Мы также можем запустить любой пользовательский скрипт как службу systemd.

Это помогает скрипту запускаться при загрузке системы.

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

В этом руководстве рассматривается запуск bash скрипта как службы Systemd.

Шаг 1 – Создайте скрипт

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

Сохраните скрипт и установите права на выполнение.

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

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

Шаг 2 – Создайте файл SystemD

Затем создайте служебный файл для systemd в вашей системе.

Этот файл должен иметь расширение .service и храниться в каталоге /lib/systemd/system/.

Шаг 3 – Включите новую службу

Ваша системная служба добавлена.

Давайте перезагрузим демон systemctl, чтобы система прочитала новый файл.

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

Теперь разрешите запуск службы при загрузке системы, а также запустите службу с помощью следующих команд.

Заключение

2 thoughts on “ 📜 Как запустить shell скрипт как службу SystemD на Linux ”

Спасибо за материал!

Добавить комментарий Отменить ответ

Вопрос: Как отладить/найти изменения или неудачные команды во время процесса загрузки? 1. В процессе загрузки, при появлении загрузочного меню grub нажмите “e” для редактирования grub, затем прокрутите вниз, пока не увидите запись boot: echo "Loading Linux. linux16 /vmlinuz-XXX root=XXXro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8 2. В строке с “linux” удалите следующие записи, если они.

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

Когда вы посещаете официальный сайт LXLE, его мантра – “Оживите старый ПК” – смело бросается в глаза. И это именно то, что LXLE стремится сделать. Основанный на релизе Ubuntu/Lubuntu LTS, LXLE – это легкий дистрибутив Linux, дружественный к ресурсам и идеально подходящий для старых ПК или систем с низкими системными характеристиками. Фактически, LXLE занимает видное.

Мы знаем, что Linux является самой безопасной и надежной операционной системой с открытым исходным кодом. Выбирая Linux для компьютера, мы можем попробовать любые дистрибутивы, которые нам нравятся, такие как Ubuntu, OpenSUSE, Fedora и так далее. Но у ноутбуков есть своя специфика. Многие современные лептопы по своим характеристикам сравнимы с компьютерами, а иногда они превосходят модели.

Ранее на моем сайте уже выходила статья автозагрузка в Ubutnu. Там был рассмотрен метод автозагрузки с использованием файла rc.local. Но данный метод в современных дистрибутивах уже отключен, и считается устаревшим. Рассмотрим как пример создание простого systemd unit.

Что такое systemd?

unitd работает с сервисами описанными в своей конфигурации. Основой для создания сервиса служит юнит (unit) — это текстовый файл с описанием на подобии ini файла в системе windows. Конфигурационный файл состоит из секций. Внутри каждой секции указываются необходимые параметры. Обязательными во всех юнитах являются две секции, остальные используются в зависимости от типа юнита.

Каталоги хранения юнитов

/usr/lib/systemd/system — юниты поставляемые вместе с системой и устанавливаемыми приложениями
/run/systemd/system — юниты созданные динамически (в рантайме)
/etc/systemd/system — юниты системного администратора (тут и будем хранить наши)

Юниты systemd

target — группирует модули
service — отвечает за запуск сервисов (служб) и поддерживает вызов интерпретаторов для исполнения пользовательских скриптов
mount — занимается монтированием файловых систем
automount — автомонтирование файловых систем, используется при обращении к точке монтирования;
swap — отвечает за подключение файла подкачки
timer — запускает модули по расписанию, аналог cron
socket — запуск модуля при подключению к сокету
slice — группировка других модулей в контейнер (дерево) cgroups
device — использует реакцию на подключение какого-либо устройства
path — запуск модуля по событию доступа по конкретному пути в файловой системе

Пример юнита sshd

Давайте рассмотрим данные секции подробнее. В секции [Unit] перечислена основная информация о юните и его зависимостях. В секции [Service] указано какими командами нужно запускать, останавливать, перезапускать сервис. От какого пользователя он должен быть запущен и т.п. В секции [Install] указываем на каком уровне должен стартовать сервис (по аналогии с runlevel).

Статус юнита openssh

Description — описание юнита для большего понимания
Documentation — документация по процессу sshd
After — зависимость, т.е. в данном случае запускать юнит только после запуска network.target и sshd-keygen.target
Wants — еще одна зависимость, означает желательно. В примере Wants=sshd-keygen.target, т.е. желательно чтобы было запущено sshd-keygen.target . Желательно но не обязательно.

[Service]

Type — типы запуска служб. Могут быть

simple (по умолчанию) — происходит незамедлительный запуск этой службы, с учетом того что процесс не разветвляется (fork). Не используйте simple если пользуетесь очередностью запуска. Одно исключение это активация сокета.
forking — служба считается запущенной после того, после разветвления процесса с завершением родительского процесса. Используется для запуска классических демонов исключая случаи, когда в таком поведении процесса нет необходимости. Также желательно указать PIDFile=, чтобы systemd мог отслеживать основной процесс.
oneshot — удобен для скриптов, которые выполняют одно задание и завершаются. При необходимости можно задать параметр RemainAfterExit=yes, чтобы systemd считал процесс активным даже после его завершения.
notify — идентичен параметру simple, но с оговоркой, что демон пошлет systemd сигнал о своей готовности. Эталонная реализация данного уведомления представлена в libsystemd-daemon.so.
dbus — служба считается находящейся в состоянии готовности, когда указанный параметр BusName появляется в системной шине DBus.
idle — откладывается выполнение двоичного файла службы до момента выполнения всех остальных задач. В остальном поведение аналогично simple.

Далее в разделе Service

EnvironmentFile — файлы переменного окружения
ExecStart — полный путь к исполняемому файлу программы с параметрами запуска
ExecReload — полный пусть к исполняемому файлу программы с параметрами перезапуска программы
KillMode — указывается как будет завершен процесс. В данному случае параметр process говорит о том что будет закрыт только главный процесс
Restart — перезагрузка процесса, параметр on-failure указывает на автоматическую перезагрузку в случает отказа процесса
RestartSec — время ожидания через которое процесс должен перезагрузиться

[Install]

WantedBy — указывает на каком урове запуска стартует сервис, параметр multi-user.target указывает на запуск в многопользовательском режиме без графики

Файлы с юнитами кладем в каталог /etc/systemd/system/

Итак начнем создание простого systemd unit, подопытным будет утилита мониторинга системы nmon. Откроем на редактирование файл юнита

Добавим туда следующий код

Добавить юнит в автозагрузку можно командой

Enabled nmon

Команда запуска юнита

Статус можно посмотреть командой

В данном случае процесс после запуска закрылся, потом как при старте был указан ключ -V. Он запустился вывел версию nmon и закрылся.

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

Для получения подробной информации по systemd, можно зайти на сайт разработчика.

Собственно вопрос, как сделать из Bash скрипта в Linux сервис (демон), с возможностью проверки его на работоспособность перезапуском в случаи сбоя или зависания?

1 ответ 1

Для этой цели можно создать юнит systemd. Для начала нужно создать файл с названием my.service и поместим его в /etc/systemd/system.

Раздел [Unit] хранит общие сведения о юните. В данном случае он содержит только описание (Description).

Раздел [Service] объединяет сведения, необходимые для выполнения юнитом его задач. Type определяет тип сервиса (не путайте его с разновидностями юнитов), oneshot означает, что сервис должен выполнить разовую задачу и завершиться. ExecStop указывает скрипт, который должен быть выполнен перед остановкой сервиса. Есть еще ExecStart, этот параметр используется чаще и определяет команду, которая должна быть выполнена сразу после запуска сервиса. RemainAfterExit=true предписывает systemd считать процесс активным после его завершения.

Секция [Install] содержит сведения о том, при каких обстоятельствах должен быть запущен сервис. WantedBy=multi-user.target устанавливает запуск при обычной загрузке компьютера.

Далее нужно поместить ваш скрипт (my) в /usr/local/bin/ . Командами:

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

Более подробно можете ознакомиться в этой статье и в man. Также может быть полезна статья с хабра.

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