Для чего нужна служба init linux

Обновлено: 18.05.2024

При запуске init читает файл конфигурации /etc/inittab. Пока система работает, она перечитает его, если пошлет сигнал HUP (kill -HUP 1); эта функция избавляет от необходимости загружать систему, чтобы изменения в конфигурации инициализации вступили в силу.

Файл /etc/inittab немного сложен. Мы начнем с простого случая настройки строк getty. Строки в /etc/inittab состоят из четырех полей, разделенных двоеточием:

id — идентифицирует строку в файле. Для строк getty он указывает терминал, на котором он работает (символы после /dev/tty в имени файла устройства). Для остальных строк это не имеет значения (за исключением ограничений по длине), но оно должно быть уникальным.

runlevels — уровни запуска, для которых следует рассматривать строку. Уровни выполнения задаются однозначными цифрами без разделителей. (Уровни выполнения описаны в следующем разделе.)

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

process — запускаемая команда Linux.

Что такое init.d?

Все эти службы работают с несколькими сценариями, и эти сценарии хранятся в /etc/init.d. init — это демон, который является первым процессом системы Linux. Затем с помощью init запускаются другие процессы, службы и демоны. Итак, init.d — это база данных конфигурации для процесса инициализации.

В каталоге /etc/init.d есть множество файлов. Каждый из этих файлов представляет собой службу, то есть демон, который может работать или не работать в системе. Файлы представляют собой просто сценарии оболочки Linux, которые можно запустить либо с помощью init, либо вручную из командной строки. Все сценарии имеют некоторые одинаковые части. Если сервис должен быть запущен, вызывается функция «старт», если он должен быть остановлен, то вызывается функция «стоп». Таким образом, каждый скрипт имеет несколько функций для надлежащего реагирования на различные подкоманды службы: запуск, остановка, статус и т. д.

Каталог /etc/init.d

В Linux есть несколько служб, которые можно запускать и останавливать в системе вручную. Некоторыми из этих служб являются ssh, HTTP, tor, apache и т. д. Для запуска и запуска этих служб мы просто вводили «имя службы» start/stop/status/restart.

Пример:

И чтобы проверить, запущена ли эта служба, набираем команду:

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

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

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

Каталог /etc/rc.local

Есть также каталог /etc/rc.local. Начинает сбивать с толку то, для чего нужны все эти каталоги и файлы.

Итак, если у вас есть локальные скрипты, которые вы как администратор хотите запускать при запуске системы, вы можете поместить их в каталог /etc/rc.local, и они запустятся автоматически.

Служебная команда

Команда службы используется для запуска сценария инициализации System V. Обычно все сценарии инициализации системы V хранятся в каталоге /etc/init.d, а служебные команды могут использоваться для запуска, остановки и перезапуска демонов и других служб в Linux. Все сценарии в /etc/init.d принимают и поддерживают как минимум команды запуска, остановки и перезапуска.

Подкоманды	Значение
имя службы start	Запускает службу
остановка имени службы	Остановка службы
перезапуск имени службы	Перезапуск службы
обновление имени службы	Перезагружает конфигурацию
статус имени службы	Проверяет, запущена ли служба
service –status-all	Отображает статус всех услуги

Команда chkconfig

Команда chkconfig очень похожа на команду службы и используется для отображения списка всех доступных служб, а также для просмотра или обновления их параметров уровня выполнения. В нем указана текущая информация о запуске служб или какой-либо конкретной службы, обновление настроек уровня запуска службы и добавление или удаление службы из управления.

В следующей таблице используется только ОПЦИЯ --list, хотя есть и несколько других опций. Дополнительную информацию см. на справочной странице chkcofig. В этих примерах замените SERVICE на соответствующее имя службы.

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

Я подписан на несколько списков рассылки, связанных с различными дистрибутивами и приложениями Linux, просто чтобы быть в курсе того, что и где происходит. Какие новые баги? Какие патчи выпущены?Что ожидается в следующем релизе? и много всего другого. В наши дни список рассылки переполнен сообщениями «Выбери свою сторону в Linux Divide», в основном в списке рассылки Debian и некоторых других.

Что такое «Выбери свою сторону в Linux Divide»?

Демон инициализации будет заменен демоном systemd в некоторых дистрибутивах Linux, хотя во многих из них он уже реализован. Это создаст/будет создавать огромный разрыв между традиционным Unix/Linux Guard и новым Linux Guard – программистами и системными администраторами.

В этой статье мы обсудим и решим все вопросы один за другим.

Что такое инициализация?
Что такое systemd?
Почему нужно было заменить init?
Какие функции будут принадлежать systemd.

Что такое инициализация?

В Linux init — это сокращение от Initialization. Init — это процесс-демон, который запускается, как только компьютер запускается, и продолжает работать до тех пор, пока он не выключится. На самом деле init — это первый процесс, который запускается при загрузке компьютера, что прямо или косвенно делает его родительским для всех других запущенных процессов, поэтому обычно ему назначается «pid=1».

Если каким-либо образом не удалось запустить демон инициализации, ни один процесс не будет запущен, и система достигнет стадии, называемой «Паника ядра». init чаще всего называют System V init. System V — это первая коммерческая операционная система UNIX, и использование init в большинстве современных дистрибутивов Linux идентично OS System V, за некоторыми исключениями, такими как Slackware, использующая стиль BSD, и Gentoo, использующая пользовательскую инициализацию.

Upstart — демон замены инициализации, реализованный в Ubuntu GNU/Linux и предназначенный для асинхронного запуска процесса.
Epoch — демон замены инициализации, основанный на простоте и управлении службами и предназначенный для однопоточного запуска процессов.
Mudar — демон замены инициализации, написанный на Python, реализованный в Pardus GNU/Linux и предназначенный для асинхронного запуска процесса.
systemd — демон замены инициализации, предназначенный для параллельного запуска процессов, реализованный в ряде стандартных дистрибутивов — Fedora, OpenSuSE, Arch, RHEL, CentOS и т. д.

Что такое systemd?

Systemd — это демон управления системой, названный в соответствии с соглашением UNIX о добавлении «d» в конце имени демона. Так, чтобы их можно было легко узнать. Первоначально он был выпущен под лицензией GNU General Public License, но теперь выпуски производятся под лицензией GNU Lesser General Public License. Подобно init, systemd прямо или косвенно является родителем всех других процессов и является первым процессом, который запускается при загрузке, поэтому обычно ему присваивается «pid=1».

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

Почему возникла необходимость заменить init?

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

Возможности systemd

Чистый, передовой и эффективный дизайн.
Упрощенный процесс загрузки.
Одновременная и параллельная обработка при загрузке.
Улучшенный API.
Простой синтаксис единиц.
Возможность удаления дополнительных компонентов.
Мало памяти.
Улучшенный метод выражения зависимостей.
Инструкция по инициализации записана в файле конфигурации, а не в сценарии оболочки.
Используйте сокет домена Unix.
Планирование заданий с использованием календарных таймеров systemd.
Ведение журнала событий с помощью journald.
Выбор регистрации системных событий с помощью systemd и syslog.
Журналы хранятся в двоичном файле.
состояние systemd можно сохранить для последующего вызова в будущем.
Отслеживание процесса с использованием контрольной группы ядра, а не PID.
Вход пользователей управляется systemd-logind.
Улучшенная интеграция с Gnome для обеспечения совместимости.

Узкие места в системе

Все в одном месте.
Не стандарт POSIX.

Интеграция Systemd и дистрибутива

Полемика

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

systemd и инициализация

Заключение

Все, что работает с pid=1, не должно ломаться, не должно быть беспорядка и должно контролироваться пользователями эффективно и действенно. Многие пользователи считают, что замена init на systemd — это не что иное, как изобретать велосипед каждый раз как побочный эффект Linux. Но в этом разнообразная природа Linux. Это потому, что Linux настолько мощен. Изменения — это хорошо, и мы должны ценить их, если они происходят по уважительной причине.

На этом пока все. Я вернусь сюда снова с еще одной интересной статьей, которую вы, люди, будете любить читать. А пока следите за обновлениями и подключайтесь к Tecmint. Не забудьте поделиться с нами своим ценным отзывом в комментариях ниже.

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

Если вы цените то, что мы делаем здесь, в TecMint, вам следует подумать о следующем:

TecMint – это самый быстрорастущий и пользующийся наибольшим доверием сайт сообщества, где можно найти любые статьи, руководства и книги по Linux в Интернете. Миллионы людей посещают TecMint! для поиска или просмотра тысяч опубликованных статей, доступных всем БЕСПЛАТНО.

Если вам нравится то, что вы читаете, купите нам кофе (или 2) в знак признательности.

Мы благодарны за вашу бесконечную поддержку.

Что такое демон инициализации?

Демон инициализации — это первый процесс, выполняемый ядром Linux, и его идентификатор процесса (PID) всегда равен 1. Его назначение — инициализация, управление и отслеживание системных служб и демонов. Другими словами, демон инициализации является родителем всех процессов в системе.

Что такое инициализация?

Init (также известный как System V init или SysVinit) — это демон инициализации, созданный в 1980-х годах, который определяет шесть уровней выполнения (состояний системы) и сопоставляет все системные службы с этими уровнями выполнения. Это позволяет запускать все службы (определяемые как сценарии) в заранее определенной последовательности. Следующий сценарий выполняется только в том случае, если выполняется текущий сценарий в последовательности, или истекает время ожидания, если он зависает. Помимо неожиданного ожидания во время тайм-аута выполнения, последовательный запуск служб делает процесс инициализации системы неэффективным и относительно медленным.

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

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

Что такое Systemd?

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

Чтобы создать службу, вам потребуется написать файл .service, хранящийся в каталоге /etc/systemd/system. Вы должны написать файл /etc/systemd/system/myService.service, который выглядит примерно так:

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

Заключение

Init и Systemd являются демонами инициализации, но лучше использовать последний, так как он широко используется в последних дистрибутивах Linux. Init использует службу, тогда как Systemd использует systemctl для управления службами Linux.

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

Для чего нужна служба init linux

Что такое init.d?

Каталог /etc/init.d

Каталог /etc/rc.local

Служебная команда

Команда chkconfig

Предпосылки

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

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

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

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

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

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

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

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

systemd default.target

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

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

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

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

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

Заключение

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

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

Что такое «Выбери свою сторону в Linux Divide»?

Что такое инициализация?

Что такое systemd?

Почему возникла необходимость заменить init?

Возможности systemd

Узкие места в системе

Интеграция Systemd и дистрибутива

Полемика

systemd и инициализация

Заключение

Если вы цените то, что мы делаем здесь, в TecMint, вам следует подумать о следующем:

Похожие записи

69 мыслей о «История init и systemd: почему init нужно было заменить на systemd в Linux»

Есть что сказать? Присоединяйтесь к обсуждению. Отменить ответ

Что такое демон инициализации?

Что такое инициализация?

Что такое Systemd?

Заключение