Текст книги "Внутреннее устройство Linux"

Автор книги: Брайан Уорд

сообщить о нарушении

Текущая страница: 12 (всего у книги 30 страниц) [доступный отрывок для чтения: 13 страниц]

Одним из недостатков команды Upstart является отсутствие возможности простого отслеживания событий. Можно перевести ее журнал в режим отладки, в результате чего в нем будут отображены все входящие события (как правило, этот журнал хранится в файле /var/log/syslog), однако обилие посторонней информации в этом файле затрудняет определение контекста события.

6.5.2. Задания команды Upstart

Каждый файл в каталоге конфигурации /etc/init команды Upstart соответствует какому-либо заданию, а главный файл конфигурации для каждого задания снабжен расширением .conf. Например, файл /etc/init/mountall.conf определяет задание mountall.

Существуют два первичных типа заданий Upstart.

• Задачи (Task jobs). Это задания с четким окончанием. Например, задание mountall является таковым, поскольку оно завершается по окончании монтирования файловых систем.

• Службы (Service jobs). У таких заданий нет определенного окончания. Серверы (демоны), такие как udevd, серверы баз данных и веб-серверы, являются заданиями-службами.

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

Просмотр заданий

Просмотреть задания команды Upstart, а также их статус можно с помощью команды initctl. Чтобы получить обзор того, что происходит в вашей системе, запустите такую команду:

$ initctl list

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

mountall stop/waiting

Он сообщает о том, что задание mountall находится в статусе «останов/ожидание», и это означает, что оно не работает. К сожалению (на момент написания книги), вы не сможете использовать статус, чтобы определить, запущено ли уже задание или еще нет, поскольку статус «останов/ожидание» применяется также и к никогда не запускавшимся заданиям.

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

tty1 start/running, process 1634

Эта строка говорит о том, что задание tty1 запущено и процесс с идентификатором ID 1634 выполняет его. Не все службы обладают связанными процессами.

примечание

Если вам известно имя задания job, можно просмотреть его статус напрямую с помощью команды initctl status job.

Информация о статусе в результатах вывода команды initctl (например, stop/waiting) может сбивать с толку. Левая часть (до символа /) является целью, или тем, по направлению к чему призвано работать данное задание (например, запуск или останов). Правая часть сообщает текущее состояние задания или то, что данное задание выполняет именно сейчас (например, ожидание или работа). В приведенном выше листинге задание tty1 обладает статусом start/running, это значит, что его целью является запуск. Состояние работы говорит о том, что задание запущено успешно. Для служб состояние работы является номинальным.

Случай с заданием mountall немного другой, поскольку задачи не остаются в рабочем состоянии. Статус «останов/ожидание» обычно говорит о том, что данное задание стартовало и завершило свою задачу. По завершении задачи цель меняется с запуска на останов, и теперь задание ожидает дальнейших указаний команды Upstart.

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

примечание

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

Переходы между состояниями заданий

Существует множество состояний заданий, однако для переключения между ними установлен четкий порядок. Вот как, например, запускается типичное задание.

1. Все задания начинаются в статусе «останов/ожидание».

2. Когда пользователь или системное событие запускают задание, цель задания меняется с останова на запуск.

3. Команда Upstart изменяет состояние задания с ожидающего на стартующее, поэтому теперь его статус – «запуск/запуск» (start/starting).

4. Команда Upstart порождает событие starting job.

5. Задание выполняет все, что необходимо сделать для состояния запуска.

6. Команда Upstart изменяет состояние задания со стартующего на предстартовое и порождает событие pre-start job.

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

8. Команда Upstart порождает событие started.

Завершение задания содержит похожий набор изменений состояния и событий. Обратитесь к странице руководства upstart-events(7), чтобы узнать подробности обо всех состояниях и переходах для обеих целей.

6.5.3. Конфигурация команды Upstart

Исследуем два файла конфигурации: один для задачи mountall, а другой – для сервиса tty1. Подобно другим файлам конфигурации, данные файлы расположены в каталоге /etc/init и называются mountall.conf и tty1.conf. Файлы конфигурации составлены из небольших фрагментов, которые называются строфами. Каждая строфа начинается с заглавного ключевого слова, например description или start.

Для начала откройте на своем компьютере файл mountall.conf. Отыщите в первой строфе нечто подобное приведенной ниже строке:

description      "Mount filesystems on boot"

Эта строфа дает краткое текстовое описание задания.

Далее вы увидите несколько строф, описывающих процесс запуска задания mountall:

start on startup

stop on starting rcS

Здесь первая строка говорит команде Upstart о запуске задания при возникновении события startup (это начальное событие, порождаемое командой Upstart). Вторая строка сообщает команде Upstart о том, что задание следует остановить при возникновении события rcS, когда система перейдет в режим одиночного пользователя.

Следующие строки говорят команде Upstart о том, как себя ведет задание mountall:

expect daemon

task

Строфа task говорит команде Upstart о том, что данное задание является задачей, и поэтому в какой-то момент должно быть завершено. Строфа expect чуть сложнее. Она означает, что задание mountall породит демон, который будет действовать независимо от исходного сценария задания. Команде Upstart необходимо знать о том, когда демон прекращает работу, чтобы дать правильный сигнал о завершении задания mountall. Более подробно мы рассмотрим это в пункте «Отслеживание процессов и строфа expect команды Upstart» далее.

Файл mountall.conf продолжается далее несколькими строфами emits, указывающими на события, которые порождает данное задание:

emits virtual-filesystems

emits local-filesystems

emits remote-filesystems

emits all-swaps

emits filesystem

emits mounting

emits mounted

примечание

Как отмечалось в подразделе 6.5.1, присутствующие здесь строки не сообщают о настоящих источниках событий. Чтобы их отыскать, вам придется тщательно просмотреть сценарий задания.

Вам может также встретиться строфа console, определяющая, куда должна направлять вывод команда Upstart:

console output

Если указан параметр output, команда Upstart отправляет вывод задания mountall в системную консоль.

Теперь вы увидите подробности самого задания – в данном случае это строфа script:

script

    . /etc/default/rcS

    [ -f /forcefsck ] && force_fsck="—force-fsck"

    [ "$FSCKFIX" = "yes" ] && fsck_fix="-fsck-fix"

    # set $LANG so that messages appearing in plymouth are translated

    if [ -r /etc/default/locale ]; then

        . /etc/default/locale

        export LANG LANGUAGE LC_MESSAGES LC_ALL

    fi

    exec mountall —daemon $force_fsck $fsck_fix

end script

Это сценарий оболочки (см. главу 11), основная часть которого является подготовительной: происходит настройка языка сообщений, а также определяется необходимость использования утилиты fsck. Реальные действия происходят в команде exec mountall, в нижней части этого сценария. Эта команда монтирует файловые системы и порождает события по окончании данного задания.

Служба: tty1

Служба tty1 намного проще, она контролирует строку приглашения в виртуальной консоли. Полный файл конфигурации tty1.conf выглядит так:

start on stopped rc RUNLEVEL=[2345] and (

            not-container or

            container CONTAINER=lxc or

            container CONTAINER=lxc-libvirt)

stop on runlevel [!2345]

respawn

exec /sbin/getty -8 38400 tty1

Самой сложной частью данного задания является момент его запуска, но пропустите пока строки, содержащие слово container, и сосредоточьтесь на следующем фрагменте:

start on stopped rc RUNLEVEL=[2345]

Эта часть сообщает команде Upstart, чтобы она активизировала данное задание после возникновения события stopped rc, когда отработает и будет завершена задача rc. Чтобы условие стало истинным, задание rc должно также установить для переменной окружения RUNLEVEL значение от 2 до 5 (см. подраздел 6.5.6).

примечание

Другие задания, которые работают с уровнями запуска, не столь требовательны. Вы можете встретить, например, такую запись: start on runlevel [2345]. Единственное существенное различие между двумя приведенными строфами start заключается в выборе момента времени; данный пример активизирует задание, как только будет установлен уровень запуска, а в предыдущем примере ожидается завершение всех процессов System V.

Здесь присутствует конфигурация контейнера, поскольку команда Upstart работает не только напрямую поверх ядра системы Linux с реальными аппаратными средствами, но способна также работать и в виртуальных средах или контейнерах. Некоторые из таких сред не располагают виртуальными консолями, и вам не придется запускать процесс getty для несуществующей консоли.

Остановка задания tty1 происходит просто:

stop on runlevel [!2345]

Строфа stop говорит команде Upstart о том, что задание следует остановить, если уровень запуска выйдет из диапазона значений от 2 до 5 (например, во время выключения системы).

Строфа exec в нижней части является командой, которую следует запустить:

exec /sbin/getty -8 38400 tty1

Эта строфа очень похожа на строфу script, которую вы видели в задании mountall, за исключением того, что для запуска задания tty1 не требуется сложная настройка – оно просто запускается одной строкой. В данном случае мы запускаем команду выдачи строки приглашения getty в устройстве /dev/tty1, которое является первой виртуальной консолью (той, в которой вы окажетесь, когда нажмете в графическом режиме сочетание клавиш Ctrl+Alt+F1).

Строфа respawn дает распоряжение команде Upstart о перезапуске задания tty1, если оно завершается. В данном случае команда Upstart запускает новый процесс getty для новой строки приглашения, когда вы выходите из виртуальной консоли.

Это были основы конфигурации команды Upstart. Подробности вы сможете найти на странице руководства init(5), а также в онлайн-источниках. Одной строфе следует уделить особое внимание. Это строфа expect, и о ней пойдет речь дальше.

Отслеживание процессов и строфа expect команды Upstart

Поскольку команда Upstart отслеживает процессы в заданиях, как только они запущены (чтобы она могла эффективно останавливать и перезапускать их), ей необходимо знать, какие процессы относятся к каждому из заданий. Эта задача может оказаться сложной, поскольку в традиционной схеме запуска системы Unix процессы ответвляются друг от друга, превращаясь в демоны, и основной процесс для какого-либо задания может начаться после одного-двух ветвлений. Без четкого отслеживания процессов команда Upstart будет неспособна завершить запуск задания или же неправильно определит идентификатор PID для задания.

Поведение задания сообщается команде Upstart с помощью строфы expect. Существует четыре основные возможности:

• отсутствие строфы expect – основной процесс задания не ветвится, следует отслеживать основной процесс;

• expect fork – процесс ветвится один раз, следует отслеживать ответвившийся процесс;

• expect daemon – процесс ветвится дважды, следует отслеживать второе ответвление;

• expect stop – основной процесс задания подаст сигнал SIGSTOP, чтобы сообщить о своей готовности. Такое бывает редко.

Для команды Upstart и для других современных вариантов команды init, таких как systemd, идеальным вариантом является первый (отсутствие строфы expect), поскольку основному процессу задания не приходится задействовать никаких собственных механизмов запуска и завершения. Другими словами, ему не приходится заботиться об ответвлении или откреплении себя от текущего терминала, с которыми разработчикам систем Unix приходится сталкиваться годами.

Во многие традиционные служебные демоны уже включены параметры стиля отладки, которые дают указание главному процессу, чтобы он не ветвился. В качестве примера можно привести демон защищенной оболочки sshd с параметром -D. Заглянув в строфы запуска в файле /etc/init/ssh.conf, можно обнаружить простую конфигурацию запуска демона sshd, которая предотвращает быстрое повторное ветвление и исключает ложный вывод в стандартную ошибку:

respawn

respawn limit 10 5

umask 022

# 'sshd -D' leaks stderr and confuses things in conjunction with 'console log'

console none

–snip—

exec /usr/sbin/sshd -D

Для заданий, которым необходимо наличие строфы expect, самым распространенным является вариант expect fork. Вот, например, пусковой фрагмент файла /etc/init/cron.conf:

expect fork

respawn

exec cron

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

примечание

Стоит прочитать дополнительную информацию о строфе expect на сайте upstart.ubuntu.com, поскольку она напрямую относится к продолжительности действия процессов. Можно, например, отслеживать активность процесса и его системные вызовы, включая fork(), с помощью команды strace.

6.5.4. Управление командой Upstart

В дополнение к командам list и status, описанным в подразделе 6.5.2, можно также использовать команду initctl, чтобы управлять командой Upstart и ее заданиями. Вам потребуется прочитать страницу руководства initctl(8), но сейчас рассмотрим основы.

Чтобы запустить задание Upstart, используйте команду initctl start:

# initctl start job

Чтобы остановить задание, применяйте команду initctl stop:

# initctl stop job

Чтобы перезапустить задание:

# initctl restart job

Если вам необходимо породить событие для команды Upstart, это можно выполнить вручную с помощью такой команды:

# initctl emit event

Можно также добавить к порожденному событию переменные окружения, указав после события event параметры в виде пар key=value.

примечание

Невозможно запускать и останавливать отдельные службы, запущенные в режиме совместимости команды Upstart со стандартом System V. Из подраздела 6.6.1 вы больше узнаете о том, как это выполняется в сценариях System V init.

Существует множество способов отключить задание Upstart, чтобы оно не стартовало при загрузке системы, однако самым управляемым является следующий: определите имя файла конфигурации задания (обычно это файл /etc/init/<job>.conf), а затем создайте новый файл с именем /etc/init/<job>.override, который содержит всего одну строку:

manual

После этого единственным способом запуска указанного задания станет применение команды initctl start job.

Основным преимуществом данного метода является его простая обратимость. Чтобы заново задействовать задание при загрузке системы, удалите файл .override.

6.5.5. Журналы команды Upstart

Существуют два основных типа журналов команды Upstart: журналы служб и диагностические общения, которые создает сама команда Upstart. Журналы служб записывают стандартный вывод и стандартную ошибку сценариев и демонов, которые запускают службы. Такие сообщения, хранящиеся в каталоге /var/log/upstart, являются дополнением к стандартным сообщениям, которые может выдавать служба syslog (о сообщениях syslog вы узнаете подробнее в главе 7). Сложно систематизировать записи, попадающие в эти журналы, поскольку нет стандартов. Наиболее часто встречаются сообщения о запуске и остановке, а также сообщения об аварийных ошибках. Многие службы вообще не оставляют никаких сообщений, поскольку они отправляют все в журнал syslog или в собственное средство записи событий.

Собственный диагностический журнал команды Upstart может содержать информацию о том, когда она была запущена и перезагружена, а также некоторую информацию о заданиях и событиях. Этот диагностический журнал поступает в утилиту ядра syslog. В ОС этот журнал можно, как правило, найти в файле /var/log/kern.log, а также во всеохватном файле /var/log/syslog.

В то же время команда Upstart по умолчанию заносит в журнал очень мало записей или совсем ничего, поэтому, если вы желаете увидеть что-либо в журналах, необходимо изменить приоритет журнала команды Upstart. По умолчанию имя приоритета равно message. Чтобы заносить в журнал сведения о событиях и изменениях заданий в работающей системе, поменяйте значение приоритета на info:

# initctl log-priority info

Помните о том, что это изменение не станет постоянным и будет сброшено после перезагрузки. Чтобы команда Upstart при своем запуске заносила в журнал все, добавьте в качестве параметра загрузки ключ —verbose, как описано в разделе 5.5.

6.5.6. Уровни запуска команды Upstart и совместимость со стандартом System V

К настоящему моменту мы затронули несколько областей, в которых команда Upstart поддерживает идею уровней запуска System V, а также отметили, что она обладает возможностью запуска сценариев System V в качестве заданий. Приведу более детальный обзор того, как это выглядит в Ubuntu.

1. Запускается задание rc-sysinit обычно после возникновения событий filesystem и static-network-up. До запуска этого задания уровни запуска отсутствуют.

2. Задание rc-sysinit определяет, на какой уровень запуска перейти. Как правило, это уровень запуска по умолчанию, однако задание может проверить также «старый» файл /etc/inittab или взять значения уровня запуска из параметра ядра (в файле /proc/cmdline).

3. Задание rc-sysinit запускает команду telinit, чтобы изменить уровень запуска. Эта команда порождает событие runlevel, которое задает значение уровня запуска в переменной окружения RUNLEVEL.

4. Команда Upstart получает сигнал о событии runlevel. Несколько заданий настроено на запуск при возникновении события runlevel и установке определенного уровня запуска, вследствие чего команда Upstart приводит их в действие.

5. Одно из заданий, активизированных по уровню запуска, rc, отвечает за запуск системы System V. Чтобы это выполнить, задание rc запускает сценарий /etc/init.d/rc, подобно тому как это выполнила бы команда System V init (см. раздел 6.6).

6. По завершении задания rc команда Upstart может запустить другие задания, когда будет получен сигнал о событии stopped rc (например, задание tty1, о котором шла речь в пункте «Служба: tty1» подраздела 6.5.3).

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

В любом случае есть критическая точка во время загрузки системы, когда монтируются файловые системы и производится наиболее важная часть инициализации ОС. В этот момент система готова к запуску высокоуровневых системных служб, таких как менеджеры графического дисплея и серверы баз данных. Событие runlevel удобно, как метка для этого момента. Хотя можно было бы настроить команду Upstart на использование любого события в качестве триггера. Затруднение возникает при попытке определить, какие службы запускаются в качестве заданий команды Upstart, а какие запускаются в режиме совместимости с версией System V. Простейший способ выяснить это – заглянуть в ферму ссылок уровня запуска System V (см. подраздел 6.6.2). Например, если уровень запуска равен 2, посмотрите каталог /etc/rc2.d. Все, что в нем находится, работает, вероятно, в режиме совместимости с версией System V.

примечание

Замешательство может вызвать наличие фиктивных сценариев в каталоге /etc/init.d. Для любой службы команды Upstart здесь может также находиться сценарий для такой службы в стиле System V, однако этот сценарий не делает ничего другого, кроме как сообщает вам о том, что служба была конвертирована в задание команды Upstart. Не будет также ссылки на этот сценарий в каталоге ссылок System V. Если вам встретится фиктивный сценарий, выясните имя задания Upstart, а затем используйте команду initctl для управления этим заданием.

6.6. Команда System V init

Реализация команды System V init восходит к «юности» Linux. Ее основная идея заключается в поддержке упорядоченной загрузки системы на различные уровни запуска с помощью тщательно подобранной последовательности запуска процессов. Хотя вариант System V сейчас не распространен в большинстве версий ОС для ПК, вы можете встретить команду System V init в версии Red Hat Enterprise Linux, а также во внедренных средах Linux (например, для роутеров и смартфонов).

В типичный состав команды System V init входят два главных компонента: центральный файл конфигурации и большой набор сценариев загрузки системы, дополненный фермой символических ссылок. Все начинается с конфигурационного файла /etc/inittab. Если вы работаете с вариантом System V init, отыщите строку, подобную приведенной ниже, в файле inittab:

id:5:initdefault:

Она сообщает о том, что по умолчанию устанавливается уровень запуска 5.

Все строки файла inittab построены по следующему шаблону, в котором четыре поля отделяются двоеточиями:

• уникальный идентификатор (короткая строка, как id в приведенном примере);

• применимое значение уровня запуска (или несколько значений);

• действие, которое следует выполнить команде init (в приведенном примере – установить по умолчанию значение 5 для уровня запуска);

• команда на выполнение (необязательна).

Чтобы увидеть, как работают команды в файле inittab, рассмотрим следующую строку:

l5:5:wait:/etc/rc.d/rc 5

Эта особая строка важна, поскольку она приводит в действие большую часть системной конфигурации и служб. Здесь действие wait определяет, когда и как команда System V init запускает команду: она должна запустить один раз команду /etc/rc.d/rc 5 при переходе на уровень запуска 5, а затем, прежде чем делать что-либо еще, дождаться завершения ее работы. Чтобы «сократить историю», команда rc 5 выполняет все, что находится в каталоге /etc/rc5.d и начинается с числа (в порядке следования чисел).

Ниже приводится еще несколько распространенных действий из файла inittab в дополнение к initdefault and wait.

Действие respawn

Действие respawn говорит команде init о том, чтобы она запустила следующую дальше команду и, если выполнение команды завершилось, запустила ее снова. Вам, вероятно, встретится подобная строка в файле inittab:

1:2345:respawn:/sbin/mingetty tty1

Утилиты getty обеспечивают приглашение на вход. Приведенная выше строка используется для первой виртуальной консоли (/dev/tty1), которую вы видите, когда нажимаете сочетание клавиш Alt+F1 или Ctrl+Alt+F1 (см. подраздел 3.4.4). Действие respawn заново выводит приглашение на вход, когда вы выйдете из системы.

Действие ctrlaltdel

Действие ctrlaltdel управляет тем, что выполняет система, когда вы нажимаете сочетание клавиш Ctrl+Alt+Delete в виртуальной консоли. В большинстве систем это команда перезагрузки, использующая команду shutdown (о которой рассказано в разделе 6.7).

Действие sysinit

Действие sysinit команда должна выполнить в самую первую очередь, перед переходом на какой-либо из уровней запуска.

примечание

О других доступных действиях можно узнать на странице руководства inittab(5).

6.6.1. Команда System V init: командная последовательность запуска

Теперь вы готовы узнать, как команда System V init запускает системные службы, прежде чем она позволяет вам войти в систему. Вспомните приведенную выше строку из файла inittab:

l5:5:wait:/etc/rc.d/rc 5

Эта небольшая строка приводит в действие множество других команд. На самом деле символы rc являются сокращением от run commands (запустить команды), под которыми многие подразумевают сценарии, программы и службы. Но где расположены эти команды?

Число 5 в этой строке сообщает о том, что речь идет об уровне запуска 5. Вероятно, команды будут находиться в каталоге /etc/rc.d/rc5.d или /etc/rc5.d. Уровень запуска 1 использует каталог rc1.d, уровень запуска 2 – rc2.d и т. д. Например, вы можете встретить подобные файлы в каталоге rc5.d:

S10sysklogd    S20ppp          S99gpm

S12kerneld     S25netstd_nfs   S99httpd

S15netstd_init S30netstd_misc  S99rmnologin

S18netbase     S45pcmcia       S99sshd

S20acct        S89atd

S20logoutd     S89cron

Команда rc 5 запускает утилиты из каталога rc5.d, выполняя команды в такой последовательности:

S10sysklogd start

S12kerneld start

S15netstd_init start

S18netbase start

–snip—

S99sshd start

Обратите внимание на аргумент start в каждой команде. Прописная буква S в имени команды означает, что данная команда должна работать в режиме запуска, а число (от 00 до 00) определяет местоположение команды rc в последовательности команд. Команды из каталогов rc*.d обычно являются сценариями оболочки, запускающими команды из каталога /sbin или /usr/sbin.

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

примечание

Некоторые каталоги rc*.d содержат команды, которые начинаются с символа K (для режима останова). В таком случае команда rc запускает команду с аргументом stop вместо аргумента start. Чаще всего команды с символом K будут встречаться вам на уровнях запуска, отвечающих за выключение системы.

Такие команды можно запускать вручную. Однако обычно это осуществляется не с помощью каталогов rc*.d, а с использованием каталога init.d, о котором речь пойдет ниже.

6.6.2. Ферма ссылок команды System V init

Содержимое каталогов rc*.d в действительности является символическими ссылками на файлы, расположенные в другом каталоге, init.d. Если вы намерены взаимодействовать со службами из каталогов rc*.d, добавлять, удалять или изменять службы, вам необходимо понимать такие символические ссылки. Полный список содержимого такого каталога, как rc5.d, обнаруживает подобную структуру:

lrwxrwxrwx . . . S10sysklogd -> ../init.d/sysklogd

lrwxrwxrwx . . . S12kerneld -> ../init.d/kerneld

lrwxrwxrwx . . . S15netstd_init -> ../init.d/netstd_init

lrwxrwxrwx . . . S18netbase -> ../init.d/netbase

–snip—

lrwxrwxrwx . . . S99httpd -> ../init.d/httpd

–snip—

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

Запуск и останов служб

Чтобы вручную запустить или остановить службы, используйте сценарий из каталога init.d. Например, одним из способов ручного запуска веб-сервера httpd является запуск сценария init.d/httpd start. Подобным же образом для остановки работающей службы можно применять аргумент stop (httpd stop, например).

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

Изменение последовательности запуска системы в команде System V init обычно выполняется с помощью изменения фермы ссылок. Самое распространенное изменение – запрет работы какой-либо команды из каталога init.d на определенном уровне запуска. Следует внимательно относиться к тому, как это осуществлено. Например, вы могли бы решить удалить символическую ссылку из соответствующего каталога rc*.d. Но будьте осторожны: если вам когда-нибудь понадобится вернуть эту ссылку обратно, у вас могут возникнуть трудности при указании точного имени ссылки. Одним из лучших способов является добавление символа подчеркивания (_) в начало имени ссылки, например так:

# mv S99httpd _S99httpd

Это приводит к тому, что команда rc игнорирует файл _S99httpd, поскольку его имя не начинается с символа S или K, однако при этом исходное имя по-прежнему очевидно.

Чтобы добавить службу, создайте сценарий, подобный тем, которые находятся в каталоге init.d, а затем создайте символическую ссылку в правильном каталоге rc*.d. Проще всего это выполнить с помощью копирования и изменения одного из сценариев, который вы понимаете (в главе 11 содержится дополнительная информация о сценариях оболочки).

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

6.6.3. Утилита run-parts

Механизм, который команда System V init использует для запуска сценариев из каталога init.d, находит себе применение в различных версиях Linux, вне зависимости от того, используют ли они команду System V init. Это утилита run-parts, единственной ее задачей является запуск подборки исполняемых команд из указанного каталога в некотором предсказуемом порядке. Можно представлять себе эту команду как исполнителя, запускающего для некоторого каталога команду ls, а затем просто выполняющего все команды, которые видит в результатах вывода.

По умолчанию запускаются все команды из каталога, однако зачастую у вас есть возможность выбрать определенные команды и игнорировать остальные. В некоторых версиях системы у вас не будет большого контроля над работающими программами. Например, Fedora поставляется с очень простым вариантом утилиты run-parts.

Другие версии, такие как Debian и Ubuntu, располагают более сложной командой run-parts. Их функции содержат возможность запуска команд на основе регулярных выражений (например, используя выражение S[0-9]{2} для запуска всех сценариев «запуск» из каталога уровня запуска /etc/init.d), а также для передачи аргументов командам. Такие возможности позволяют вам запускать и останавливать уровни запуска System V с помощью единственной команды.

Нет необходимости разбираться в деталях использования утилиты run-parts; многие даже и не знают о ее существовании. Главное – помнить о том, что она время от времени возникает в сценариях и служит только для того, чтобы запускать команды из указанного каталога.