Почему некоторые скрипты нуждаются в постоянном повторном поиске во время debian init?

Изучая сценарии инициализации, я озадачен тем, почему некоторые вспомогательные функции необходимо повторно использовать снова и снова. В частности, функции регистрации, найденные в /lib/lsb/init-functions . Каждый скрипт, который хочет, чтобы сообщения журналов нуждались в повторном источнике, почему бы не сделать это один раз и все?

Кажется, что каждый новый скрипт инициализации запускается в собственной оболочке. Если это так, зачем это так? Эта же проблема возникает с помощью «vars.sh», которая должна постоянно обновляться. Это необходимо? Предположим, что «init-functions» и «vars.sh» были добавлены в список скриптов для запуска на соответствующих уровнях выполнения?

  • Возобновление Linux из спящего режима на ThinkPad X220 происходит с черным экраном или перезагрузкой
  • Ошибка обновления nginx в Stretch
  • Quagga перестала работать после обновлений в Stretch
  • В чем разница между системами SysV и SysV при изменении уровней запуска?
  • Всегда пытайтесь остановить демона при выключении без файла блокировки в / var / lock / subsys /
  • Почему я иногда вижу «INIT: version 2.88 reloading» в консоли?
  • Ошибка перезапуска rsyslog
  • Что означает `init ` в столбце COMMAND ps?
  • 2 Solutions collect form web for “Почему некоторые скрипты нуждаются в постоянном повторном поиске во время debian init?”

    Много вопросов …

    Основной ответ на ваш вопрос: да, каждый скрипт запускается в собственной оболочке, или, скорее, каждый процесс, который получает exec'd, содержит копию базовой среды + эти переменные, которые включаются в этот источник + любые дополнительные переменные среды, которые включены при запуске службы.

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

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

     $ free -m total used free shared buffers cached Mem: 7782 7086 696 0 218 883 -/+ buffers/cache: 5984 1797 Swap: 7823 1550 6273 

    Строка- -/+ buffers/cache – это кеширование этих типов блоков, связанных с дисковым вводом-выводом.

    Будущие направления

    Большая часть инициализации происходит из системы V (см. Статью в Википедии об init для полной истории). По сегодняшним меркам он устарел, но он прослужил около 20 лет. Но есть определенные области, где это недостаточно.

    Поэтому, чтобы попытаться решить эти проблемы, 2 новичка, Systemd & Upstart были разработаны и начинают использоваться различными дистрибутивами Linux.

    ss # 1

    Принятие Upstart было немного горки. Он разработан компанией Canonical, так что он уже давно находится в Ubuntu и в течение некоторого времени был частью Fedora, а также RHEL, CentOS и openSUSE, прежде чем они перешли на systemd. На самом деле это все еще в RHEL & CentOS.

    Обе эти системы делают заметные улучшения по сравнению с SysV init, особенно в том, что касается возможности одновременного запуска служб. Один из основных недостатков init. Но с этими системами ушла простота, открывая пару скриптов в vim и настраивая ваши запущенные процедуры. Это и полномасштабные технологии, которые требуют времени, чтобы понять и полностью понять.

    Насколько я видел, только сценарии в /etc/init.d/ и /etc/network /lib/lsb/init-functions файлы в /lib/lsb/init-functions , они не получаются снова и снова, только один раз для каждого скрипта и каждого сценарий должен быть источником его один раз, потому что каждый скрипт можно запускать отдельно.

    [Редактировать # 1]

    Важно знать, когда файл читается один раз, он будет кэшироваться системой. Поэтому, если файл должен быть снова прочитан, это не займет времени. Кроме того, файлы в /etc/lsb/init-functions содержат только определение подпрограмм, они не будут выполняться при получении.

    [Редактировать # 2]

    Я проверил это еще раз и хотел узнать, сколько времени требуется, чтобы указать какой-то скрипт. Поэтому я переключился на init 1, чтобы убедиться, что никакой другой процесс не нарушает измерение. Вот результаты:

     find /lib/lsb -type f -ls 9951842 4 -rw-r--r-- 1 root root 1088 Jun 5 2013 /lib/lsb/init-functions.d/20-left-info-blocks 9952149 4 -rw-r--r-- 1 root root 2408 Dec 31 19:24 /lib/lsb/init-functions.d/40-systemd 9951841 12 -rw-r--r-- 1 root root 11506 May 15 2013 /lib/lsb/init-functions 

    Таким образом, это 3 скрипта и около 15 тыс. Памяти

    Тест представляет собой простую петлю bash

     time bash -c 'for i in {1..10000}; do source /lib/lsb/init-functions; done' real 0m27.342s user 0m17.756s sys 0m1.328s 

    Это означает, что 27.342 / 10000/3 = 0,0009 секунды в среднем для исходного сценария на 3.4Ghz Core 2 Duo.

    Linux и Unix - лучшая ОС в мире.