Практичне застосування знань про підсистему rc.d. отриманих з офіційної документації BSD далеко не завжди буває простою справою для новачка. У цій статті ми розглянемо кілька типових варіантів скриптів запуску, покажемо, як використовувати можливості rc.d в кожному з цих випадків і обговоримо як це працює. Цей огляд повинен дати вам кончина про підсистемі rc.d для подальшої ефективної розробки.
Колись BSD мала монолітний скрипт запуску / etc / rc. Його викликав init (8) під час завантаження системи, і цей скрипт виконував всі завдання в просторі користувача (userspace), необхідні для багатокористувацьких операцій: перевірку і монтування файлових систем, налаштування мережі, запуск демонів тощо. Але список таких завдань не однаковий в різних системах, адміністраторам необхідна більш тонка настройка. За винятком окремих моментів, / etc / rc легко піддавався модифікації, і по-справжньому зосереджені люди часто і з задоволенням його модифікували.
Основна проблема подібного монолітного рішення полягала в тому, що воно не надавало механізму контролю над окремими компонентами, що запускаються з скрипта / etc / rc. Наприклад, / etc / rc не міг перезапустити окремий сервіс. Системного адміністратора доводилося знаходити ідентифікатор процесу вручну, вбивати цей процес, чекати, фактичного завершення процесу, знаходити в файлі / etc / rc параметри, з якими цей процес був запущений, вручну запускати процес з командного рядка. Ця послідовність дій ставала ще більш заплутаною і складною, якщо перезапускати сервіс породжував кілька процесів або вимагав додаткових дій при запуску. У двох словах, монолітний скрипт запуску не міг виконати основне завдання всіх скриптів - зробити життя системного адміністратора простіше.
Пізніше були зроблені спроби розділити / etc / rc на частини, метою винести деякі найбільш важливі елементи. Чудовий приклад цього - скрипт / etc / netstart. започатковано роботу мережі. Цей скрипт дозволяв запустити мережу з розрахованого на одного користувача режиму, але його неможливо було повноцінно інтегрувати в систему автозапуску, оскільки частини коду, що мають відношення до мережі потрібно було чергувати з частинами, до мережі не відносяться. З цієї причини скрипт / etc / netstart згодом мутував в /etc/rc.network. Останній вже не є абсолютно незалежним скриптом, він складається з великих, взаємозалежних функцій, написаних на sh (1). які, в свою чергу, викликаються з / etc / rc на різних етапах запуску системи. Тим часом, оскільки скрипти запуску стали більше, між ними з'явилися складні залежності, '' квазі-модульна '' система запуску стала ще заплутаніше, ніж монолітний скрипт / etc / rc.
Без простою і прозорою підсистеми стартові скрипти стали ще менше задовольняти потреби швидко розвиваються BSD-систем. Стало очевидно, що необхідні принципові кроки до досягнення модульности і гнучкості rc системи запуску. Виходячи з цих міркувань і була створена система запуску BSD rc.d. Її визнаними батьками стали Люк Мьюберн (Luke Mewburn) і співтовариство NetBSD. Пізніше ця система була імпортована в FreeBSD. Її назва посилається на розташування системних скриптів для окремих сервісів, які розташовуються в /etc/rc.d. Трохи пізніше ми розглянемо окремі компоненти системи rc.d і побачимо, як запускаються окремі скрипти.
Загальна ідея системи запуску BSD rc.d полягає у високому ступені модульності і повторне використання коду. Високий ступінь модульності значить, що кожен окремий '' сервіс '', такий як системний демон або найпростіша задача, використовують свій власний скрипт, написаний на sh (1). який може запускати, зупиняти, перезапускати цей сервіс і перевіряти його статус. Стандартне дію вибирається з командного рядка скрипта. / Etc / rc так само як і раніше є основним завантажувальним скриптом, але тепер він не виконує весь процес завантаження, а викликає окремі скрипти з параметром start. Так само легко виконується зупинка системи - для цього запускається цей же набір скриптів, але з аргументом stop. Ця дія виконується керуючим скриптом /etc/rc.shutdown. Зверніть увагу, наскільки точно ця система запуску відповідає традиційному в Unix принципом - використовувати набір маленьких спеціалізованих інструментів, кожен з яких покликаний вирішувати конкретну задачу. Повторне використання коду це підхід, який означає, що часто використовуються операції реалізовані у вигляді функцій на мові sh (1) і об'єднані в файл / etc / rc.subr. Тепер типовий скрипт може складатися всього з декількох рядків коду на мові sh (1). І нарешті, дуже важлива частина підсистеми rc.d - програма rcorder (8). яка яка допомагає скрипту / etc / rc запускати окремі скрипти в певному порядку з урахуванням залежностей між ними. В тому числі, вона так само допомагає скрипту /etc/rc.shutdown. оскільки правильний порядок завершення роботи системи протилежний порядку під час запуску.
Є кілька вимог для повного розуміння викладеного матеріалу. По-перше, ви повинні бути знайомі з програмуванням на скриптовій мовою sh (1). По-друге, ви повинні розуміти як система здійснює стартові і завершальні дії простору користувача, які описані в rc (8).
Маленьке зауваження перед початком. Не бійтеся змінної оточення $ EDITOR.
Для того, щоб писати якісні rc.d скрипти для системних сервісів нам потрібно відповісти на наступні питання:
Цей сервіс обов'язковий чи ні?
Буде скрипт обслуговувати тільки одну програму (тобто демон) або буде виконувати більш комплексні завдання?