как узнать какая система инициализации используется в linux

linux-notes.org

Иногда интересно какая же инициализация используется на сервере и в моей статье «Система инициализации в Unix/Linux» я расскажу как можно узнать какая система инициализации используется на сервере.

Основные системы инициализации:

Команды по системам инициализации в Unix/Linux ОС:

Система инициализации в Unix/Linux

Существует несколько способов проверить это, сейчас я покажу как это сделать.

-=== СПОСОБ 1 — проверка PID процессов==-

Например, Ubuntu до версии 14 использовала систему инициализацию Upstart чтобы проверить это, выполните:

Например, Ubuntu 16 и CentOS 7 использовала систему инициализацию SystemD чтобы проверить это, выполните:

Или если используется Ubuntu 16, можно выполнить:

Или (если чтобы было красиво):

Например, CentOS 6 использовала систему инициализацию Upstart, но с init процессом и чтобы проверить это, выполните:

-=== СПОСОБ 2 — проверка файлов==-

Запускаем следующую команду:

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

ИЛИ, можно выполнить:

Вот вам еще довольно стоящий пример:

-=== СПОСОБ 3 — с помощью ФС==-

Можно запустить следующую команду:

Команда что выше, проверяет exe симлинку в папке /proc/1. А собственно «1» – это PID 1-го процесса.

-=== СПОСОБ 4 — с помощью готового bash скрипта==-

И прописываем в него:

Можно добавить прав на исполнение:

И для запуска, юзаем:

-=== СПОСОБ 5 — с помощью пакетного менеджера==-

Если используете centOS/RedHat/Fedora/Suse, то можно выполнить:

Если используете Debian/Ubuntu/Mint/др, то можно выполнить:

-=== СПОСОБ 6 — с помощью lsof==-

Так же, можно выполнить:

-=== СПОСОБ 7 — с помощью ls и which==-

Вот и все. Если имеются другие примеры проверки инициализации, пишите в комментариях. Тема «Система инициализации в Unix/Linux» завершена.

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

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

Источник

Система инициализации

Просмотры

Введение

Система инициализации Linux — это набор скриптов, выполняющихся при старте системы. Скрипты написаны на языке shell-script классического Boure Shell (sh).

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

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

В Linux наибольшее распространение получила система инициализации System V. Ее используют такие дистрибутивы как:

Система инициализации BSD используется в дистрибутиве Slackware Linux и его производных.

Если говорить о SystemV — это очень строгая система инициализации. где шаг вправо или влево — расстрел на месте. Правда некоторые дистрибутивы (не буду тыкать в них пальцем, хотя это был Red Hat) даже из такой строгой системы могут сделать чёрт те что и сбоку бантик.

В системе инициализации BSD не наблюдается строгих правил, но соблюдаются определенные принципы её построения. Поэтому если рассматривать дистрибутивы и операционные системы использующие ее, можно сказать, что это организованный бардак :). Т.е. нет двух похожих систем в которых совпадало бы именование файлов и их порядок вызова. Но все прекрасно понимают как это работает.

Последовательность действий при старте компьютера

При запуске PC совместимого компьютера происходит следующая последовательность действий:

То есть, в результате мы имеем:

Дальнейшие действия, которые будут выполняться при старте системы, во многом зависят от конфигурации программы init.

Так же хочется обратить ваше внимание на то, что до этого момента ещё не важно какая система инициализации используется. Не зависимо от неё во всех Linux сначала запускается init. А вот какая система инициализации будет использоваться в дальнейшем зависит от того как сконфигурирован init.

Время не стоит на месте

Как говориться: «Всё течёт, всё меняется». В современных дистрибутивах наблюдается тенденция к использованию отличных от классического init систем. По моему мнению, это связано с распространением Linux на рабочих станциях, где большую роль играет время загрузки.

Не хочу копипастить материалы у себя, просто приведу ссылочку на хороший перевод статьи, посвященной systemd.

Источник

Администрирование систем Linux. Инициализация системы и уровни исполнения

Глава 15. Инициализация системы и уровни исполнения

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

15.1. Инициализация системы

15.1.1. Процесс с идентификатором 1

15.1.2. Параметры конфигурации в файле /etc/inittab

15.1.3. Переменная initdefault

С помощью значения переменной initdefault указывается стандартный уровень исполнения (default runlevel). В некоторых дистрибутивах Linux в файле /etc/inittab приводится краткое описание уровней исполнения подобное приведенному ниже переведенному описанию из соответствующего файла дистрибутива Red Hat Enterprise Linux 4.

15.1.4. Сценарий sysinit

Следующая строка файла конфигурации /etc/inittab в дистрибутиве Red Hat и производных дистрибутивах выглядит следующим образом:

Приведенная выше команда egrep может быть заменена на аналогичную приведенную ниже команду grep :

В дистрибутиве Debian после строки с переменной initdefault используется следующая строка:

Сценарий /etc/init.d/rcS в дистрибутиве Debian будет выполняться всегда (независимо от выбранного уровня исполнения). Данный сценарий на самом деле осуществляет исполнение всех сценариев из директории /etc/rcS.d/ с сортировкой имен этих сценариев в алфавитном порядке.

15.1.5. Сценарии инициализации

Демон инициализации продолжит чтение конфигурационного файла /etc/inittab и перейдет к приведенной ниже секции в случае использования дистрибутива Debian Linux.

15.1.6. Директории для хранения сценариев инициализации

Все эти операции выполняются силами сценария /etc/rc.d/rc в дистрибутиве Red Hat и сценария /etc/init.d/rc в дистрибутиве Debian.

15.1.7. Демоны mingetty

Описание демонов mingetty в конфигурационном файле /etc/inittab

Демоны mingetty и исполняемый файл /bin/login

Перезапуск демонов mingetty

Демон инициализации осуществляет запуск демонов mingetty и отслеживает их состояние вплоть до завершения их работы (это происходит тогда, когда пользователь прекращает работу с командной оболочкой и осуществляет выход из системы). Когда это случается, демон инициализации осуществляет повторный запуск новой копии демона mingetty. Исходя из этого, даже в том случае, если вы принудительно завершите работу демона mingetty, он будет автоматически перезапущен.

В приведенном ниже примере показано, как демон инициализации перезапускает демоны mingetty. Обратите внимание на идентификаторы двух последних процессов mingetty.

При использовании утилиты kill для завершения работы двух последних демонов mingetty демон инициализации будет обрабатывать сигналы завершения работы дочерних процессов и снова запускать их (с отличными идентификаторами процессов).

Деактивация демонов mingetty

В примере ниже показана методика деактивации демонов mingetty для терминалов tty3 и tty6 на уровнях исполнения 4 и 5.

15.2. Daemon или demon?

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

При разговоре о демонах Unix не следует путать слова daemons и demons. Evi Nemeth, соавтор книги «Unix System Administration Handbook» говорил о демонах следующее:

Многие уравнивают слово «daemon» со словом «demon», намекая на некоторую адскую связь между системами Unix и преисподней. Это утверждение свидетельствует о вопиющем непонимании. На самом деле, слово «daemon» является более старой формой слова «demon»; слово daemon не имеет определенного отношения к добру или злу, а вместо этого служит для описания характера или личностных качеств человека. Древнегреческая концепция «личного демона» была схожа с современной концепцией «ангела-хранителя».

15.3. Запуск и остановка демонов

К примеру, в данном случае мы осуществляем перезапуск демона samba.

15.4. Утилита chkconfig

В данном случае мы используем утилиту chkconfig для вывода списка состояний службы на различных уровнях исполнения. Как вы видите, демон (или служба) crond активируется только на уровнях исполнения со 2 по 5.

15.4.2. Установка уровней исполнения для службы

Обратившись к приведенному ниже примеру, вы можете узнать о том, как использовать утилиту chkconfig для деактивации (или активации) службы на определенном уровне исполнения.

В этом примере показано, как деактивировать службу crond на уровне исполнения 3.

А в этом примере показано, как активировать эту же службу crond на уровнях исполнения 3 и 4.

15.4.3. Конфигурационные данные, используемые утилитой chkconfig

Каждый сценарий в директории /etc/init.d/ может содержать дополнительные строки (и комментарий), сообщающие утилите chkconfig от том, что следует сделать со службой в той или иной ситуации. Строка, начинающаяся с # chkconfig: содержит список уровней исполнения, на которых служба должна запускаться (2345), за которым следуют значения приоритетов запуска (90) и остановки (60) службы.

15.4.4. Активация и деактивация служб

Службы могут быть активированы и деактивированы на всех уровнях исполнения с помощью единственной команды. Уровни исполнения 0, 1 и 6 всегда связаны с остановкой служб (или вызовом сценариев с передачей параметра stop ) даже в том случае, если имя сценария начинается с буквы S в верхнем регистре.

15.5. Утилита update-rc.d

15.5.1. Об утилите update-rc.d

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

15.5.2. Удаление системной службы

В данном случае мы удалим упоминание о системной службе cron на всех уровнях исполнения. Помните о том, что корректный способ деактивации системной службы заключается в размещении в директориях всех уровней исполнения ссылки на сценарий с именем, начинающимся с буквы K.

15.5.3. Активация системной службы

В данном примере показана методика использования утилиты update-rc.d для активации системной службы на уровнях исполнения 2, 3, 4 и 5, а также деактивации системной службы на уровнях исполнения 0, 1 и 6.

15.5.4. Нестандартная конфигурация системной службы

А в данном примере показана методика использования разработанной вами нестандартной конфигурации демона crond.

15.6. Утилита bum

15.7. Уровни исполнения

15.7.1. Вывод информации об уровне исполнения

Команда runlevel является стандартной командой Linux и выводит информацию о предыдущем и текущем уровнях исполнения. В том случае, если предыдущего уровня исполнения не было, в качестве номера будет выведена буква N.

15.7.2. Изменение уровня исполнения

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

15.7.3. Утилита /sbin/shutdown

Утилита shutdown используется для корректного завершения работы системы.

В данном примере показана методика использования утилиты shutdown с пятисекундным интервалом между отправкой сигналов TERM и KILL.

15.7.4. Утилиты halt, reboot и poweroff

15.7.5. Файл журнала /var/log/wtmp

15.7.6. Сочетание клавиш Ctrl+Alt+Del

После того, как сценарий rc завершит исполнение всех описанных сценариев для управления службами, демон инициализации init продолжит читать файл конфигурации /etc/inittab. В следующей строке описано поведение демона инициализации в том случае, если пользователь нажмет клавиши Alt+Ctrl+Del на клавиатуре.

Ниже приведена команда, используемая в дистрибутиве Debian 4.0.

Данная команда очень похожа на стандартную команду, используемую в дистрибутиве Red Hat Enterprise Linux 5.2.

15.7.7. ИБП и отключение питания компьютера

15.8. Менеджер инициализации systemd

Можно предположить с высокой вероятностью, что менеджер инициализации systemd заменит все стандартные функции компонентов систем инициализации init/runlevel/rc. Разработчики дистрибутивов Red Hat и Debian в 2014 году приняли решение о том, что systemd заменит стандартные системы инициализации в следующих выпусках их дистрибутивов (RHEL/CentOS7 и Debian 8).

Цели введены в качестве замены уровней исполнения и описывают определенные точки, которые должны быть достигнуты при загрузке системы. К примеру, цель graphical.target достигается тогда, когда вы получаете возможность работы с графическим интерфейсом, а цель nfs.target требует наличия функционирующего сервера nfs.

Для изменения цели, установленной по умолчанию, мы должны снова использовать команду systemctl (вместо редактирования файла /etc/inittab ).

15.8.2. Зависимости systemd

Дистрибутив Debian 8 пока не полностью мигрировал на systemd.

15.8.3. Службы systemd

В данном примере показан новый способ запуска и остановки системной службы.

А это новый способ остановки и деактивации системной службы.

В данном примере показан способ повторной активации и запуска системной службы.

15.8.4. Отправка сигналов при работе с systemd

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

15.8.5. Завершение работы системы средствами systemd

Таблица 15.1. Управление питанием системы средствами systemd

15.8.6. Удаленное использование systemd

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

15.8.7. Комплект поставки systemd включает большее количество утилит

Существуют и другие инструменты.

Например, с помощью команды systemd-analyze blame можно получить список всех служб с временем загрузки каждой из них.

15.9. Практическое задание: системы инициализации

2. Запустите дистрибутив Red Hat Enterprise Linux в виртуальной машине. Перейдите на уровень исполнения 5, выполните команду, позволяющую вывести информацию о текущем и предыдущем уровне исполнения, после чего перейдите на уровень исполнения 3.

3. Выясните, выполняет ли сценарий sysinit установку или изменение значения переменной окружения PATH на ваших компьютерах?

4. Выведите список всех сценариев из директории init.d, которые запускаются при достижении уровня исполнения 2.

6. Используйте утилиту chkconfig для того, чтобы ваш сценарий запускал демон при достижении уровней исполнения 3, 4 и 5 и останавливал его при достижении любого другого уровня исполнения.

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

2. Запустите дистрибутив Red Hat Enterprise Linux в виртуальной машине. Перейдите на уровень исполнения 5, выполните команду, позволяющую вывести информацию о текущем и предыдущем уровне исполнения, после чего перейдите на уровень исполнения 3.

init 5 (изменение уровня исполнения можно отследить по выводу в консоли)

init 3 (и снова вы можете отследить изменение уровня исполнения по выводу в консоли)

3. Выясните, выполняет ли сценарий sysinit установку или изменение значения переменной окружения PATH на ваших компьютерах?

4. Выведите список всех сценариев из директории init.d, которые запускаются при достижении уровня исполнения 2.

Сценарий должен выглядеть аналогично приведенному ниже сценарию.

Команда touch /var/lock/subsys/pold необходима и должна осуществлять создание файла с именем, идентичным имени сценария в том случае, если вы хотите задействовать сценарий в последовательности прекращения работы демонов (для этого также необходимо создать ссылку на сценарий с именем K01pold).

6. Используйте утилиту chkconfig для того, чтобы ваш сценарий запускал демон при достижении уровней исполнения 3, 4 и 5 и останавливал его при достижении любого другого уровня исполнения.

Источник

Как узнать, использует ли система SysV, Upstart или Systemd initsystem [duplicate]

У этого вопроса уже есть ответ:

Какие существуют методы проверки такой initsystem?

5 ответов

/usr/lib/systemd сообщает, что вы находитесь в системе на основе systemd.

/etc/init.d сообщает вам, что в его истории есть SysV init

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

Процесс инициализации всегда назначается PID 1. Файловая система /proc предоставляет способ получения пути к исполняемому файлу с учетом PID.

Вы также можете выполнить его, чтобы узнать больше:

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

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

Общие не стартеры

Обнаружение системы 5 init

Обнаружение systemd

Другие, неофициальные, проверки не будут работать:

Обнаружение nosh

Другие не стартеры:

Обнаружение выскочки

Но, как и systemd API:

В системах на базе Debian вы можете сделать аналогичную вещь с dpkg :

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

Кроме того, на некоторых дистрибутивах возможно, что /sbin/init не является правильным файлом для просмотра, скорее всего, потому что init=/something/else в командной строке ядра. Другая возможность заключалась бы в том, что /sbin/init является символической ссылкой, принадлежащей некоторому вспомогательному пакету, которому поручено переключать между системами инициализации и не принадлежит ни одному из них напрямую. Один или оба из них могут иметь место в Arch (хотя у меня нет окна Arch, которое можно проверить прямо сейчас).

Из программы вы также можете использовать определенные API для этого. Systemd поставляется с libsystemd, который может проверить, может ли он успешно подключиться к исполняемому экземпляру systemd.

Источник

Системы инициализации Unix и Linux после SysV

Daniel J. Bernstein математик и специалист по криптографии, автор популярного MTA qmail и множества других менее известных программ, среди которых выделяется daemontools. Для множества современных систем инициализации daemontools являлся примером и вдохновителем. Прошу внутрь для того, чтобы познакомиться с самой элегантной, простой и влиятельной системой управления службами в Unix / Linux.

DJB и Daemontools

Уравнения Максвелла для управления процессами на Unix ОС.

Внимание — не следует путать daemontools написанный DJB с программой-тезкой DAEMON Tools для монтирования iso образов и создания виртуальных CD/DVD дисков.

Daniel J. Bernstein создал свою программу в 1997 г. Последний стабильный релиз был в июле 2001 г.

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

Почему такие странные принципы, и еще с учетом того, что автор исповедует их фанатично? Строительный материал daemontools — директории, процессы, FIFO, исполняемые файлы. Это дает массу преимуществ в разработке и отладке приложения:

Сравнительная таблица DT

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

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

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

Структура DT

Внутреннее устройство daemontools, граница обведена красной прерывистой линией.

Теперь немного о принципах работы программы.

Синтаксис команды svc и опции представлены ниже.

Попробуем добавить сервис sshd.

В таком случае структура директорий может выглядеть так.

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

Зависимости между службами

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

В данном примере программа на python запустится только в том случае, если стартовал postgres, если же последний пока не поднялся, скрипт завершится и затем через определенно время svscan его перезапустит. Когда же postgres наконец поднимется, python запустит веб приложение.

Квотирование сервиса

С помощью утилиты softlimit можно ограничить предоставленные данному сервису ресурсы.

Логирование

Из другого терминала запускаем:

Последователи daemontools

Мало кто сегодня использует DT, но можно смело сказать, что Daniel J. Bernstein стал для многих примером, а дело его живет и здравствует. Вот неполный список его последователей.

Источник