Как узнать, какая система инициализации используется в Linux
Обновлено: 21.11.2024
Это может быть больше связано с обнаружением операционных систем, но мне особенно нужна система инициализации, используемая в настоящее время в системе.
Fedora 15 и Ubuntu теперь используют systemd, Ubuntu раньше использовал Upstart (по умолчанию до 15.04), в то время как другие используют варианты System V.
У меня есть приложение, которое я пишу в качестве межплатформенного демона. Сценарии инициализации генерируются динамически на основе параметров, которые можно передать в configure.
Что я хотел бы сделать, так это сгенерировать сценарий только для конкретной системы инициализации, которую они используют. Таким образом, сценарий установки можно запускать без параметров от имени пользователя root, а демон может быть «установлен» автоматически.
Вот что я придумал:
- Ищите systemd, upstart и т. п. в /bin
- Сравните /proc/1/comm с systemd, upstart и т. д.
- Спросите пользователя
Как это лучше всего сделать на разных платформах?
Как-то связанно: могу ли я полагаться на то, что bash будет работать с большинством *nix, или это зависит от дистрибутива/ОС?
- ОС Mac
- Linux (все дистрибутивы)
- BSD (все версии)
- Solaris, Minix и другие *nix
Принятый ответ:
На второй вопрос ответ отрицательный, и вам следует обратиться к разделу Ресурсы по программированию переносимых оболочек.
Что касается первой части — в первую очередь вам, безусловно, нужно быть осторожным. Я бы посоветовал выполнить несколько тестов, чтобы убедиться, потому что тот факт, что у кого-то установлен systemd (например), не означает, что он действительно используется по умолчанию. в этом . Кроме того, просмотр /proc/1/comm может ввести в заблуждение, потому что некоторые установки различных программ инициализации могут автоматически сделать /sbin/init жесткой ссылкой или даже переименованной версией их основной программы.
Возможно, самым полезным будет взглянуть на тип сценариев инициализации, потому что это то, что вы на самом деле будете создавать, независимо от того, что их запускает.
В качестве примечания вы также можете взглянуть на OpenRC, целью которого является предоставление структуры сценариев инициализации, совместимой как с системами Linux, так и с системами BSD.
Это может быть больше связано с обнаружением операционных систем, но мне особенно нужна система инициализации, используемая в настоящее время в системе.
Fedora 15 и Ubuntu теперь используют systemd, Ubuntu раньше использовал Upstart (по умолчанию до 15.04), в то время как другие используют варианты System V.
У меня есть приложение, которое я пишу в качестве межплатформенного демона. Сценарии инициализации генерируются динамически на основе параметров, которые можно передать в configure.
Что я хотел бы сделать, так это сгенерировать сценарий только для конкретной системы инициализации, которую они используют. Таким образом, сценарий установки можно запускать без параметров от имени пользователя root, а демон может быть «установлен» автоматически.
Вот что я придумал:
- Ищите systemd, upstart и т. п. в /bin
- Сравните /proc/1/comm с systemd, upstart и т. д.
- Спросите пользователя
Как это лучше всего сделать на разных платформах?
Как-то связанно: могу ли я полагаться на то, что bash будет работать с большинством *nix, или это зависит от дистрибутива/ОС?
- ОС Mac
- Linux (все дистрибутивы)
- BSD (все версии)
- Solaris, Minix и другие *nix
@tjameson, вы нашли более прямой путь? Я ищу то же самое, но ответы здесь - это просто указания, а не прямые ответы. В частности, 1) расположение сценариев для поиска и 2) обнаружение действующей системы инициализации, если установлено несколько систем (на bash был дан прямой ответ).
@naxa – Краткий ответ: нет. Длинный ответ, вы можете продвинуться довольно далеко с помощью команды ps -p 1 -o (распечатывает путь к текущему init ). В Arch Linux и Fedora (IIRC) это символическая ссылка на двоичный файл systemd (вероятно, одинаковая во всех системах systemd). В upstart init --help выведет информацию об использовании, а в моем случае выскочка упоминается там, где указано, кому отправлять электронное письмо. Во FreeBSD (sysV) это вернет ошибку. В других системах могут быть похожие подсказки, но поскольку я задал этот вопрос, я решил просто создать их для всех платформ и сделать отдельные пакеты для каждой из них.
Ни один из ответов или комментариев в связанном вопросе не связан с bash. Решения должны быть применимы и к вашему случаю.
20 ответов 20
Я сам столкнулся с этой проблемой и решил провести несколько тестов. Я полностью согласен с ответом, что для каждого дистрибутива нужно упаковывать отдельно, но иногда есть практические проблемы, которые мешают этому (не в последнюю очередь рабочая сила).
Итак, для тех, кто хочет "автоопределить", вот что я обнаружил на ограниченном наборе дистрибутивов (подробнее ниже):
Вы можете отличить выскочку от:
Вы можете отличить systemd от:
Вы можете указать sys-v init из:
Вот мои эксперименты со следующей командной строкой:
на инстансах ec2 (я включаю идентификатор AMI восток США):
- ArchLinux: использование systemd (с 06.10.2012)
- CentOS6.4 ami-52009e3b: использование выскочки
- CentOS7 ami-96a818fe: использование systemd
- Debian 6 ami-80e915e9: использование sysv-init
- Debian 7.5 ami-2c886c44: использование sysv-init
- Debian 7.6 GCE container-vm: использование sysv-init
- RHEL 6.5 ami-8d756fe4: использование выскочки
- SLES 11 ami-e8084981: использование sysv-init
- Ubuntu 10.04 ami-6b350a02: использование выскочки
- Ubuntu 12.04 ami-b08b6cd8: использование выскочки
- Ubuntu 14.04 ami-a427efcc: использование выскочки
- Ubuntu 14.10 и младше: использование systemd
- AWS linux 2014.3.2 ami-7c807d14: использование выскочки
- Fedora 19 ami-f525389c: использование systemd
- Fedora 20 ami-21362b48: использование systemd
Просто для ясности: я не утверждаю, что это надежно! Почти наверняка это не так. Также обратите внимание, что для удобства я использую совпадения регулярных выражений bash, которые доступны не везде. Вышеупомянутого достаточно для меня прямо сейчас. Однако, если вы обнаружите дистрибутив, в котором происходит сбой, сообщите мне, и я постараюсь исправить это, если существует AMI EC2, воспроизводящий проблему.
В соответствии с документацией по systemd (sd_booted(3)), правильный способ проверить наличие systemd — это проверить, существует ли каталог /run/systemd/system.
Я добавлю к этому обнаружению launchd систему инициализации в macOS: [[ $(ps 1) =~ 'launchd' ]] && echo yes || echo не тестировалось на MacBookPro, macOS Sierra версии 10.12
Я бы еще добавил busybox: if [ -h /sbin/init -a $(readlink /sbin/init | grep busybox | wc -l) -gt 0 ]; затем эхо да; иначе эхо нет; фи
На второй вопрос ответ отрицательный, и вам следует обратиться к разделу Ресурсы по программированию переносимых оболочек.
Насчет первой части - в первую очередь, конечно, надо быть осторожным. Я бы сказал выполните несколько тестов, чтобы убедиться, потому что тот факт, что у кого-то установлен systemd (например), не означает, что он на самом деле используется по умолчанию в этом . Кроме того, просмотр /proc/1/comm может ввести в заблуждение, потому что некоторые установки различных программ инициализации могут автоматически сделать /sbin/init жесткой ссылкой или даже переименованной версией их основной программы.
Возможно, самым полезным было бы взглянуть на тип сценариев инициализации, потому что это то, что вы на самом деле будете создавать, независимо от того, что их запускает.
В качестве примечания вы также можете взглянуть на OpenRC, целью которого является предоставление структуры сценариев инициализации, совместимой как с системами Linux, так и с системами BSD.
Что вы подразумеваете под "посмотреть тип сценариев инициализации"? Часто разные системы инициализации помещают свои скрипты/файлы где-то помимо /etc/init , например, systemd помещает их в /etc/systemd . Если бы мой сценарий мог их найти, это могло бы занять некоторое время. О, и спасибо за ссылку BTW для программирования переносимой оболочки.
Я хотел сказать, что некоторые реализации инициализации можно настроить для использования различных типов и местоположений сценариев инициализации (например, /etc/rc.d/ или /etc/init.d/ ). И вы должны правильно настроить свою программу во время установки, чтобы использовать структуру, используемую в данной системе.
Итак, вы говорите, что нет надежного способа программно обнаружить систему инициализации? Передача параметров пользователем, безусловно, безопаснее, но если пользователь ничего не передает, как лучше угадать?
Я понятия не имею, какой способ лучше всего подходит для вашей программы — все зависит от того, на каких системах в конечном итоге будет работать программа. Я не использовал слишком много дистрибутивов, но я пытался поделиться своими наблюдениями, чтобы помочь вам. Это сложная часть сценария, которую вы собираетесь попробовать, и я попытался дать вам некоторое представление о поле - вы должны прийти к окончательному ответу самостоятельно или дождаться дополнительных подсказок.
Использование процессов
Взгляните на вывод пары команд ps, которые могут обнаружить различные версии systemd и upstart, которые можно создать следующим образом:
Обратите внимание, что это не init . В Ubuntu с Upstart это по-прежнему /sbin/init .
Посмотрите на процессы с ppid 1 (дочерние процессы init). (Некоторые из) имен дочерних процессов могут указывать на используемую систему инициализации.
Файловая система
Если вы запросите исполняемый файл инициализации, вы также можете получить от него некоторую информацию. Простой анализ вывода --version. Например:
ПРИМЕЧАНИЕ. Тот факт, что init находится не в стандартном месте, является своего рода подсказкой. Он всегда находится в /sbin/init в системах sysvinit.
Выводы
Таким образом, похоже, что нет какого-то одного способа сделать это, но вы можете сформулировать набор проверок, которые с достаточно высокой степенью достоверности определят, какую систему инициализации вы используете.
Спасибо, это именно то, что я искал: некоторые шаги, которые нужно предпринять, чтобы попытаться определить систему инициализации.
В моей установке kubuntu 15.04 у меня есть и systemd, и sysvinit. Не знаю, почему и что это значит, просто говорю.
Не очень эффективно, но, кажется, работает.
При совпадении нескольких строк будет напечатано больше строк, что можно перевести как "Не могу угадать". Строки, используемые в grep, могут быть немного изменены, но при тестировании в следующей ОС я всегда получал одну строку.
- RHEL 6.4 [UPSTART]
- RHEL ES 4 (обновление 7 Наханта) [SYSVINIT]
- Ubuntu 16.04.1 LTS [СИСТЕМА]
- Ubuntu 14.04.2 LTS [UPSTART]
- Выпуск 23 Fedora (онлайн-оболочка) [SYSTEMD]
- Debian GNU/Linux 7 (онлайн-оболочка) [SYSTEMD]
- Centos 7.6 (ВМ) [СИСТЕМА]
Более упрощенный подход к тому же решению (но он останавливается при первом совпадении)
Я только что попробовал это на образе докера Gentoo по умолчанию с установленным OpenRC, и он вернул SYSVINIT. Согласно wiki.gentoo.org/wiki/Comparison_of_init_systems по умолчанию для Gentoo используется OpenRC, но похоже, что OpenRC использует sysvinit. Когда я затем пытаюсь выполнить команды OpenRC, я получаю сообщение «Вы пытаетесь запустить службу OpenRC в системе, которая не загружается openrc». Есть ли способ отличить собственно sysvinit от OpenRC с помощью sysvinit?
+1. Эту команду awk можно упростить до строк -n7 /sbin/init | awk '/upstart|systemd|sysvinit/
Иногда это так же просто, как использовать ls :
Думаю, если /sbin/init не является символической ссылкой, вам придется проверить следующие предложения в других ответах.
У меня тоже была такая же проблема, и я провел много тестов на некоторых машинах RedHat/CentOS/Debian/Ubuntu/Mint. Вот что у меня получилось, с хорошими результатами.
Найти имя исполняемого файла с PID 1:
Если это systemd или Upstart, проблема решена. Если это «инициализация», это может быть символическая ссылка или что-то другое, кроме имени. Вперед.
Найти реальный путь к исполняемому файлу (работает только с правами root):
Если init является символической ссылкой на Upstart или systemd, проблема решена. В противном случае почти наверняка у вас есть SysV init. Но это может быть исполняемый файл с неправильным названием. Вперед.
Найдите пакет, содержащий исполняемый файл. К сожалению, это зависит от дистрибутива:
Тогда, если вы хотите написать это (самая забавная часть, ИМХО), вот мои однострочники (запускать от имени пользователя root):
Не все указанные операционные системы имеют dpkg или rpm (эта проблема касается не только вашего ответа, кстати).
Также может помочь проверка файловых дескрипторов. И это от фактического запуска init (Debian stretch в настоящее время позволяет установить больше систем инициализации) :-)
Возможно, более безопасным способом проверки busybox будет проверка /proc/1/exe , так как busybox обычно использует символические ссылки:
Таким образом, проверка может быть:
Для этого предназначены пакеты для конкретных дистрибутивов. Правильная установка программного обеспечения — это гораздо больше, чем просто обнаружение системы инициализации. Многие дистрибутивы используют SysVinit, но не все из них пишут свои сценарии инициализации одинаково. Правильный способ решить эту проблему — включить все различные варианты, а затем объединить их с помощью файлов спецификаций с именами зависимостей для конкретных дистрибутивов для дистрибутивов rpm, файлов deb для систем на основе apt и т. д. Почти все дистрибутивы имеют какую-то спецификацию пакета, которую вы может писать, включая зависимости, сценарии, сценарии инициализации и т. д. Не изобретайте велосипед здесь.
Нет. Что возвращает нас к 1. Если вам нужен bash, это должна быть зависимость. Вы можете указать эту проверку как часть ваших скриптов configure, но она также должна быть указана в описаниях пакетов.
Редактировать: используйте флаги в сценарии настройки, такие как --with upstart или --without sysvinit . Выберите нормальное значение по умолчанию, тогда скрипты, которые упаковывают ваше программное обеспечение для других дистрибутивов, смогут запускать его с другими параметрами.
Это может быть больше связано с обнаружением операционных систем, но мне особенно нужна система инициализации, используемая в настоящее время в системе.
Fedora 15 и Ubuntu теперь используют systemd, Ubuntu раньше использовал Upstart (по умолчанию до 15.04), в то время как другие используют варианты System V.
У меня есть приложение, которое я пишу в качестве межплатформенного демона. Сценарии инициализации генерируются динамически на основе параметров, которые можно передать в configure.
Что я хотел бы сделать, так это сгенерировать сценарий только для конкретной системы инициализации, которую они используют.Таким образом, сценарий установки можно запускать без параметров от имени пользователя root, а демон может быть «установлен» автоматически.
Вот что я придумал:
- Ищите systemd, upstart и т. п. в /bin
- Сравните /proc/1/comm с systemd, upstart и т. д.
- Спросите пользователя
Как это лучше всего сделать на разных платформах?
Как-то связанно: могу ли я полагаться на то, что bash будет работать с большинством *nix, или это зависит от дистрибутива/ОС?
- ОС Mac
- Linux (все дистрибутивы)
- BSD (все версии)
- Solaris, Minix и другие *nix
@tjameson, вы нашли более прямой путь? Я ищу то же самое, но ответы здесь - это просто указания, а не прямые ответы. В частности, 1) расположение сценариев для поиска и 2) обнаружение действующей системы инициализации, если установлено несколько систем (на bash был дан прямой ответ).
@naxa – Краткий ответ: нет. Длинный ответ, вы можете продвинуться довольно далеко с помощью команды ps -p 1 -o (распечатывает путь к текущему init ). В Arch Linux и Fedora (IIRC) это символическая ссылка на двоичный файл systemd (вероятно, одинаковая во всех системах systemd). В upstart init --help выведет информацию об использовании, а в моем случае выскочка упоминается там, где указано, кому отправлять электронное письмо. Во FreeBSD (sysV) это вернет ошибку. В других системах могут быть похожие подсказки, но поскольку я задал этот вопрос, я решил просто создать их для всех платформ и сделать отдельные пакеты для каждой из них.
Ни один из ответов или комментариев в связанном вопросе не связан с bash. Решения должны быть применимы и к вашему случаю.
20 ответов 20
Я сам столкнулся с этой проблемой и решил провести несколько тестов. Я полностью согласен с ответом, что для каждого дистрибутива нужно упаковывать отдельно, но иногда есть практические проблемы, которые мешают этому (не в последнюю очередь рабочая сила).
Итак, для тех, кто хочет "автоопределить", вот что я обнаружил на ограниченном наборе дистрибутивов (подробнее ниже):
Вы можете отличить выскочку от:
Вы можете отличить systemd от:
Вы можете указать sys-v init из:
Вот мои эксперименты со следующей командной строкой:
на инстансах ec2 (я включаю идентификатор AMI восток США):
- ArchLinux: использование systemd (с 06.10.2012)
- CentOS6.4 ami-52009e3b: использование выскочки
- CentOS7 ami-96a818fe: использование systemd
- Debian 6 ami-80e915e9: использование sysv-init
- Debian 7.5 ami-2c886c44: использование sysv-init
- Debian 7.6 GCE container-vm: использование sysv-init
- RHEL 6.5 ami-8d756fe4: использование выскочки
- SLES 11 ami-e8084981: использование sysv-init
- Ubuntu 10.04 ami-6b350a02: использование выскочки
- Ubuntu 12.04 ami-b08b6cd8: использование выскочки
- Ubuntu 14.04 ami-a427efcc: использование выскочки
- Ubuntu 14.10 и младше: использование systemd
- AWS linux 2014.3.2 ami-7c807d14: использование выскочки
- Fedora 19 ami-f525389c: использование systemd
- Fedora 20 ami-21362b48: использование systemd
Просто для ясности: я не утверждаю, что это надежно! Почти наверняка это не так. Также обратите внимание, что для удобства я использую совпадения регулярных выражений bash, которые доступны не везде. Вышеупомянутого достаточно для меня прямо сейчас. Однако, если вы обнаружите дистрибутив, в котором происходит сбой, сообщите мне, и я постараюсь исправить это, если существует AMI EC2, воспроизводящий проблему.
В соответствии с документацией по systemd (sd_booted(3)), правильный способ проверить наличие systemd — это проверить, существует ли каталог /run/systemd/system.
Я добавлю к этому обнаружению launchd систему инициализации в macOS: [[ $(ps 1) =~ 'launchd' ]] && echo yes || echo не тестировалось на MacBookPro, macOS Sierra версии 10.12
Я бы еще добавил busybox: if [ -h /sbin/init -a $(readlink /sbin/init | grep busybox | wc -l) -gt 0 ]; затем эхо да; иначе эхо нет; фи
На второй вопрос ответ отрицательный, и вам следует обратиться к разделу Ресурсы по программированию переносимых оболочек.
Насчет первой части - в первую очередь, конечно, надо быть осторожным. Я бы сказал выполните несколько тестов, чтобы убедиться, потому что тот факт, что у кого-то установлен systemd (например), не означает, что он на самом деле используется по умолчанию в этом . Кроме того, просмотр /proc/1/comm может ввести в заблуждение, потому что некоторые установки различных программ инициализации могут автоматически сделать /sbin/init жесткой ссылкой или даже переименованной версией их основной программы.
Возможно, самым полезным было бы взглянуть на тип сценариев инициализации, потому что это то, что вы на самом деле будете создавать, независимо от того, что их запускает.
В качестве примечания вы также можете взглянуть на OpenRC, целью которого является предоставление структуры сценариев инициализации, совместимой как с системами Linux, так и с системами BSD.
Что вы подразумеваете под "посмотреть тип сценариев инициализации"?Часто разные системы инициализации помещают свои скрипты/файлы где-то помимо /etc/init , например, systemd помещает их в /etc/systemd . Если бы мой сценарий мог их найти, это могло бы занять некоторое время. О, и спасибо за ссылку BTW для программирования переносимой оболочки.
Я хотел сказать, что некоторые реализации инициализации можно настроить для использования различных типов и местоположений сценариев инициализации (например, /etc/rc.d/ или /etc/init.d/ ). И вы должны правильно настроить свою программу во время установки, чтобы использовать структуру, используемую в данной системе.
Итак, вы говорите, что нет надежного способа программно обнаружить систему инициализации? Передача параметров пользователем, безусловно, безопаснее, но если пользователь ничего не передает, как лучше угадать?
Я понятия не имею, какой способ лучше всего подходит для вашей программы — все зависит от того, на каких системах в конечном итоге будет работать программа. Я не использовал слишком много дистрибутивов, но я пытался поделиться своими наблюдениями, чтобы помочь вам. Это сложная часть сценария, которую вы собираетесь попробовать, и я попытался дать вам некоторое представление о поле - вы должны прийти к окончательному ответу самостоятельно или дождаться дополнительных подсказок.
Использование процессов
Взгляните на вывод пары команд ps, которые могут обнаружить различные версии systemd и upstart, которые можно создать следующим образом:
Обратите внимание, что это не init . В Ubuntu с Upstart это по-прежнему /sbin/init .
Посмотрите на процессы с ppid 1 (дочерние процессы init). (Некоторые из) имен дочерних процессов могут указывать на используемую систему инициализации.
Файловая система
Если вы запросите исполняемый файл инициализации, вы также можете получить от него некоторую информацию. Простой анализ вывода --version. Например:
ПРИМЕЧАНИЕ. Тот факт, что init находится не в стандартном месте, является своего рода подсказкой. Он всегда находится в /sbin/init в системах sysvinit.
Выводы
Таким образом, похоже, что нет какого-то одного способа сделать это, но вы можете сформулировать набор проверок, которые с достаточно высокой степенью достоверности определят, какую систему инициализации вы используете.
Спасибо, это именно то, что я искал: некоторые шаги, которые нужно предпринять, чтобы попытаться определить систему инициализации.
В моей установке kubuntu 15.04 у меня есть и systemd, и sysvinit. Не знаю, почему и что это значит, просто говорю.
Не очень эффективно, но, кажется, работает.
При совпадении нескольких строк будет напечатано больше строк, что можно перевести как "Не могу угадать". Строки, используемые в grep, могут быть немного изменены, но при тестировании в следующей ОС я всегда получал одну строку.
- RHEL 6.4 [UPSTART]
- RHEL ES 4 (обновление 7 Наханта) [SYSVINIT]
- Ubuntu 16.04.1 LTS [СИСТЕМА]
- Ubuntu 14.04.2 LTS [UPSTART]
- Выпуск 23 Fedora (онлайн-оболочка) [SYSTEMD]
- Debian GNU/Linux 7 (онлайн-оболочка) [SYSTEMD]
- Centos 7.6 (ВМ) [СИСТЕМА]
Более упрощенный подход к тому же решению (но он останавливается при первом совпадении)
Я только что попробовал это на образе докера Gentoo по умолчанию с установленным OpenRC, и он вернул SYSVINIT. Согласно wiki.gentoo.org/wiki/Comparison_of_init_systems по умолчанию для Gentoo используется OpenRC, но похоже, что OpenRC использует sysvinit. Когда я затем пытаюсь выполнить команды OpenRC, я получаю сообщение «Вы пытаетесь запустить службу OpenRC в системе, которая не загружается openrc». Есть ли способ отличить собственно sysvinit от OpenRC с помощью sysvinit?
+1. Эту команду awk можно упростить до строк -n7 /sbin/init | awk '/upstart|systemd|sysvinit/
Иногда это так же просто, как использовать ls :
Думаю, если /sbin/init не является символической ссылкой, вам придется проверить следующие предложения в других ответах.
У меня тоже была такая же проблема, и я провел много тестов на некоторых машинах RedHat/CentOS/Debian/Ubuntu/Mint. Вот что у меня получилось, с хорошими результатами.
Найти имя исполняемого файла с PID 1:
Если это systemd или Upstart, проблема решена. Если это «инициализация», это может быть символическая ссылка или что-то другое, кроме имени. Вперед.
Найти реальный путь к исполняемому файлу (работает только с правами root):
Если init является символической ссылкой на Upstart или systemd, проблема решена. В противном случае почти наверняка у вас есть SysV init. Но это может быть исполняемый файл с неправильным названием. Вперед.
Найдите пакет, содержащий исполняемый файл. К сожалению, это зависит от дистрибутива:
Тогда, если вы хотите написать это (самая забавная часть, ИМХО), вот мои однострочники (запускать от имени пользователя root):
Не все указанные операционные системы имеют dpkg или rpm (эта проблема касается не только вашего ответа, кстати).
Также может помочь проверка файловых дескрипторов. И это от фактического запуска init (Debian stretch в настоящее время позволяет установить больше систем инициализации) :-)
Возможно, более безопасным способом проверки busybox будет проверка /proc/1/exe , так как busybox обычно использует символические ссылки:
Таким образом, проверка может быть:
Для этого предназначены пакеты для конкретных дистрибутивов. Правильная установка программного обеспечения — это гораздо больше, чем просто обнаружение системы инициализации. Многие дистрибутивы используют SysVinit, но не все из них пишут свои сценарии инициализации одинаково. Правильный способ решить эту проблему — включить все различные варианты, а затем объединить их с помощью файлов спецификаций с именами зависимостей для конкретных дистрибутивов для дистрибутивов rpm, файлов deb для систем на основе apt и т. д. Почти все дистрибутивы имеют какую-то спецификацию пакета, которую вы может писать, включая зависимости, сценарии, сценарии инициализации и т. д. Не изобретайте велосипед здесь.
Нет. Что возвращает нас к 1. Если вам нужен bash, это должна быть зависимость. Вы можете указать эту проверку как часть ваших скриптов configure, но она также должна быть указана в описаниях пакетов.
Редактировать: используйте флаги в сценарии настройки, такие как --with upstart или --without sysvinit . Выберите нормальное значение по умолчанию, тогда скрипты, которые упаковывают ваше программное обеспечение для других дистрибутивов, смогут запускать его с другими параметрами.
Мы все много раз слышали об этом слове «Системный менеджер», но лишь немногие из нас знают, что это такое. Мы покажем вам, как идентифицировать системного администратора.
Мы постараемся сообщить вам об этом. Большинство из нас знает о System V и системном менеджере systemd. System V (Sysv) — это старая и традиционная система инициализации и системный менеджер для старых систем.
Systemd — это новая система инициализации и системный менеджер, адаптированные для большинства основных дистрибутивов.
В Linux доступны три основные системы инициализации, которые очень известны и используются до сих пор. Большинство дистрибутивов Linux относятся к одной из перечисленных ниже систем инициализации.
Что такое init System Manager?
В операционных системах на базе Linux/Unix init (сокращение от Initialization) – это первый процесс, запускаемый ядром во время загрузки системы.
Идентификатор процесса (PID) равен 1. Он будет непрерывно работать в фоновом режиме, пока система не будет выключена.
Init просматривает файл /etc/inittab, чтобы определить уровень запуска Linux, а затем запускает все остальные процессы и приложения в фоновом режиме в соответствии с уровнем запуска.
Процессы BIOS, MBR, GRUB и Kernel были запущены до запуска процесса инициализации в рамках процесса загрузки Linux.
Ниже приведены доступные уровни запуска для Linux (существует семь уровней запуска, от нуля до шести).
В Linux широко используются следующие три системы инициализации.
- System V (Sys V): System V (Sys V) — одна из первых и традиционных систем инициализации для Unix-подобных операционных систем.
- Upstart: Upstart — это основанная на событиях замена демона /sbin/init.
- systemd: Systemd — это новая система инициализации и системный менеджер, которые были реализованы/адаптированы во всех основных дистрибутивах Linux вместо традиционных систем инициализации SysV.
Что такое System V (Sys V)?
System V (Sys V) — одна из первых и традиционных систем инициализации для Unix-подобных операционных систем. init — это первый процесс, запускаемый ядром во время загрузки системы, и он является родительским процессом для всего.
В большинстве дистрибутивов Linux сначала использовалась традиционная система инициализации под названием System V (Sys V). За прошедшие годы было выпущено несколько заменяющих систем инициализации для устранения ограничений дизайна в стандартных версиях, таких как launchd, Service Management Facility, systemd и Upstart.
Но systemd был принят несколькими основными дистрибутивами Linux вместо традиционных систем инициализации SysV.
Как определить системный администратор System V (Sys V) в Linux
Выполните следующие команды, чтобы определить, что ваша система работает с системным менеджером System V (Sys V).
Метод 1: Использование команды ps
ps — отчет о снимке текущих процессов. ps отображает информацию о выбранных активных процессах.
Эти выходные данные не дают точных результатов ни для System V (SysV), ни для выскочки, поэтому я бы посоветовал вам использовать другой метод, чтобы подтвердить это.
Метод 2: Использование команды rpm
RPM означает Red Hat Package Manager — мощная утилита управления пакетами командной строки для систем на базе Red Hat, таких как дистрибутивы (RHEL, CentOS, Fedora, openSUSE и Mageia). Утилита позволяет вам устанавливать, обновлять, удалять, запрашивать и проверять программное обеспечение в вашей системе/сервере Linux. Файлы RPM имеют расширение .rpm.
Пакет RPM собран с необходимыми библиотеками и зависимостями, которые не будут конфликтовать с другими пакетами, установленными в вашей системе.
Что такое Upstart?
Upstart — это основанная на событиях замена демона /sbin/init, который обрабатывает запуск задач и служб во время загрузки, останавливает их во время завершения работы и контролирует их во время работы системы.
Изначально он был разработан для дистрибутива Ubuntu, но предназначен для развертывания во всех дистрибутивах Linux в качестве замены почтенной инициализации System-V.
Он использовался в Ubuntu от 9.10 до Ubuntu 14.10 и систем на базе RHEL 6, после чего они были заменены на systemd.
Как определить системный менеджер Upstart в Linux
Выполните следующие команды, чтобы определить, что ваша система работает с системным менеджером Upstart.
Метод 1: Использование команды ps
ps — отчет о снимке текущих процессов. ps отображает информацию о выбранных активных процессах.
Эти выходные данные не дают точных результатов ни для System V (SysV), ни для выскочки, поэтому я бы посоветовал вам использовать другой метод, чтобы подтвердить это.
Метод 2: Использование команды rpm
RPM означает Red Hat Package Manager — мощная утилита управления пакетами командной строки для систем на базе Red Hat, таких как дистрибутивы (RHEL, CentOS, Fedora, openSUSE и Mageia). Команда RPM позволяет вам устанавливать, обновлять, удалять, запрашивать и проверять программное обеспечение в вашей системе/сервере Linux. Файлы RPM имеют расширение .rpm.
Пакет RPM собран с необходимыми библиотеками и зависимостями, которые не будут конфликтовать с другими пакетами, установленными в вашей системе.
Способ 3: Использование файла /sbin/init
Программа /sbin/init загрузит или переключит корневую файловую систему из памяти на жесткий диск. Это основная часть процесса загрузки. Уровень запуска в начале этого процесса — «N» (нет). Программа /sbin/init инициализирует систему в соответствии с описанием в файле конфигурации /etc/inittab.
Что такое systemd?
Systemd — это новая система инициализации и системный менеджер, которые были реализованы/адаптированы во всех основных дистрибутивах Linux вместо традиционных систем инициализации SysV.
systemd совместим со сценариями инициализации SysV и LSB. Он может работать как замена системе sysvinit. systemd — это первый процесс, запущенный ядром и имеющий PID 1.
Это родительский процесс для всего, и Fedora 15 – первый дистрибутив, в котором вместо upstart был адаптирован systemd. systemctl — это утилита командной строки и основной инструмент для управления демонами/службами systemd, такими как (запуск, перезапуск, остановка, включение, отключение, перезагрузка и состояние).
systemd использует файлы .service вместо сценариев bash (использует SysVinit). systemd сортирует все демоны по их собственным контрольным группам Linux, и вы можете увидеть системную иерархию, изучив файл /cgroup/systemd.
Как определить системного администратора systemd в Linux
Выполните следующие команды, чтобы определить, что ваша система работает с системным менеджером systemd.
Метод 1: Использование команды ps
ps — отчет о снимке текущих процессов. ps отображает информацию о выбранных активных процессах.
Метод 2: Использование команды rpm
RPM означает Red Hat Package Manager — мощная утилита управления пакетами командной строки для систем на базе Red Hat, таких как дистрибутивы (RHEL, CentOS, Fedora, openSUSE и Mageia). Утилита позволяет вам устанавливать, обновлять, удалять, запрашивать и проверять программное обеспечение в вашей системе/сервере Linux. Файлы RPM имеют расширение .rpm.
Пакет RPM собран с необходимыми библиотеками и зависимостями, которые не будут конфликтовать с другими пакетами, установленными в вашей системе.
Читайте также: