Запуск системних служб

Повноцінно завантажена Linux -система - не лише login на віртуальній консолі. Системі є чим зайнятися і окрім ідентифікації користувачів. Навіть якщо комп'ютер не працює WWW -, FTP - або поштовим сервером для "зовнішнього світу", собі самій і своїм користувачам система надає безліч послуг : відсилання завдань на друк і забезпечення їх черги, запуск завдань за розкладом, перевірка цілісності і тому подібне Набір утиліт і системних програм, призначених для надання таких послуг, прийнято називати підсистемами або службами.

Чому служать демони?

Як правило, системна служба організована так. Під час початкового завантаження запускається у фоновому режимі програма, яка упродовж роботи системи знаходиться в таблиці процесів, проте переважно не діє, чекаючи, коли її про що-небудь попросять. Для того, щоб попросити цю програму про послугу, яку вона надає, використовуються утиліти, що взаємодіють з нею по спеціальному протоколу. По аналогії з сократовским "даймонионом", який незримо присутній, за своєю ініціативою не робить нічого, не дає здійснювати погане і сприяє хорошому, таку програму стали називати "daemon". He знайомі з творчістю Платона програмісти-аматори частенько перейменовували її в "demon" (демон); на жаль, саме в такій, злегка інфернальній формі, daemon і увійшов до російськомовної термінології. Виходить, що в Linux послуги користувачам надають демони!

демон

Програма, що запускається у фоні, тривалий час перебуває в таблиці процесів. Зазвичай демон активізується по запиту призначеної для користувача програми, по мережевому запиту або по настанню якої-небудь системної події.

У ранніх версіях UNIX усе, що треба було запускати при старті системи, вписувалося в initab. Було досить зручно в одному файлі вказувати, які саме демони повинні працювати в системі, і в якому порядку їх запускати. Само поведінка демона при запуску явно розрахована на використання в inittabno методу "wait" : класичний демон запускається інтерактивно, перевіряючи правильність конфігураційних файлів і інші умови роботи, а потім самостійно йде у фон (просто роблячи fork () і завершуючи батьківський процес). Таким чином, init чекає, поки демон працює інтерактивно, а коли служба, очолювана цим демоном, готова до роботи, переходить до наступного рядка init tab. Проте часто буває так, що автор демона знати не знає, які саме умови розробники тієї або іншої версії Linux визнають придатними для запуску. Для цього ними створюється стартовий сценарій, в якому запрограмована логіка запуску і останову служби. Крім того, якщо на кожному з рівнів виконання запускається багато різних служб, спроба записувати їх запуск в ini ttab робить його громіздким і зовсім неочевидним.

Стартовий сценарій системної служби

Стартовий сценарій - програма (зазвичай написана на shell), що управляє включенням або виключенням якої-небудь властивості системи. Це може бути запуск і зупинка HTTP-сервера, активізація і деактивація мережевих налаштувань, завантаження модулів і налаштування звукової підсистеми і тому подібне. Простий стартовий сценарій зобов'язаний приймати один параметр, значення якого може бути словом "start" для запуску (включення) і "stop" для зупинки (виключення). Якщо в певному дистрибутиві Linux прийнято рішення, що стартові сценарії повинні розуміти і інші параметри, наприклад "restart" (зазвичай "stop"+"start", але не завжди) і "status" (для опитування стану), ця вимога поширюється на усі стартові сценарії. Одноманітність дозволяє, наприклад, без зусиль запускати і зупиняти демони, не з'ясовувавши, який PID процесу, що зупиняється, і який саме сигнал йому слід послати. Досить запуск написати так, щоб PID процесу відкладався в спеціальний файл (звичайне /var /run/ім'я_служби), а в зупинку вписати щось подібне до kill -правильный_сигнал " cat /var/run/ім'я_служби.

Усі стартові сценарії служб, якими може скористатися система, прийнято зберігати в каталозі /etc/rc .d/init .d (у деяких дистрибутивах, для сумісності із старими версіями UNIX, використовується /etc/init.d, іноді це просто символьне посилання на /etc/rc .d/init .d). Запустити або зупинити службу можна, просто викликавши відповідний сценарій з параметром "start" або "stop". Часто тугіше саме завдання виконує і спеціальна команда service, яка перевіряє, чи є вказаний стартовий сценарій, і запускає його.

Схема ".d"

Отже, існує спосіб однаково і гнучко управляти запуском і зупинкою кожної системної служби окремо (чи включенням і виключенням однієї властивості системи). Проте завдання цілком організувати завантаження системи, від запуску init до повноцінної роботи

· У деяких дистрибутивах Linux така команда може називатися invoke - rc.d, a команда, аналогічна описаному нижче chkconfig, - update - rc.d.

· Перша з виникаючих завдань така: найчастіше треба завантажувати не усе з розміщених в /etc/rc.d/init.d сценаріїв, тому що деякі зі встановлених в системі служб адміністратор вирішив не використовувати. Видаляти звідти не використовувані при завантаженні сценарії - значить, позбавляти адміністратора можливості запускати ці сценарії вручну.

Творцям ранніх версій UNIX прийшла в голову проста думка: написати один великий сценарій на ім'я /etc/rc, в який і заносити тільки потрібні для запуску команди виду /etc/init.d/сценарій start. Можна навіть занести туди все наявні стартові сценарії, але рядки, що запускають ті, що не використовуються, закоментувати. Така (монолітна) схема мала істотний недолік: додавання і видалення служби в систему (наприклад, додавання і видалення пакету, що містить виконувані файли служби) вимагало редагування цього файлу. Якщо врахувати, що порядок запуску служб дуже важливий (наприклад, безглуздо запускати мережеві демони до активізації мережевих налаштувань), стає ясно, що автоматична зміна такого файлу не може гарантувати нормальне завантаження системи, а значить, неприпустимо.

На допомогу прийшла тактика, відома як "схема.d". Суть її в наступному. Нехай деякий процес управляється конфігураційним файлом, вміст якого залежить від наявності і активації інших служб системи (таким процесом може бути демон централізованої журналізації syslogd, провідний журнал усіх подій системи, або мережевий метадемон inetd, що приймає мережеві запити і перетворюючий мережевий потік даних в звичайне посимвольне уведення-виведення). Тоді, щоб уникнути постійного редагування конфігураційного файлу, його перетворюють на каталог (наприклад, на додаток до файлу /etc/sysiog. conf заводиться каталог /etc/syslog.d). Кожен файл в такому каталозі відповідає налаштуванню однієї служби : при додаванні її в систему файл з'являється, при видаленні - зникає. Залишається тільки навчити той же syslog читати налаштування не лише з одного syslog.conf, але і з усіх файлів в syslog.d, і завдання вирішене.

На випадок сценаріїв, що запускаються, схема ".d" поширюється з двома доповненнями. По-перше, як вже було сказано, стартові сценарії можна запускати, а можна і не запускати. Тому сам init.d на роль ".d" - кaтaлoгa не годиться. Втім, досить організувати ще один каталог, скажімо, rc.d, і створити там посилання (для наочності краще символьні) на ті сценарії з init.d, які планується запускати при старті системи. Загальний стартовий сценарій rс якраз і займатиметься запуском стартових сценаріїв з rc d.

По-друге, необхідно забезпечити строгий порядок запуску цих сценаріїв. Теоретично це зовсім просто: відсортувати їх за абеткою, як це робить ls, і запускати підряд. Практично ж така вимога накладає обмеження на ім'я посилання в ".сі"-каталоге, тому прийнято, щоб на початку імені стояло двозначне число. Тоді, запускаючи підряд усі сценарії, відсортовані за абеткою, rс в першу чергу керуватиметься цим номером, а вже потім - назвою служби, яка після нього стоїть.

Рівні виконання

У Linux схема початкового завантаження злегка складніша, ніж звичайна ".d". Пов'язано це з тим, що одну і ту ж систему в різних випадках буває необхідно завантажувати з різним набором служб. Якщо, скажімо, використання мережі небажане, зручніше сказати щось шкоді "Система! Завантажуйся без мережі"!, чим вручну видаляти стартові сценарії усіх імовірно мережевих служб з ".d"-каталога. Необхідність вибору також виникає, якщо комп'ютер використовується як робоча станція із запуском графічного середовища і усього з нею пов'язаного або як стійковий сервер, управляти яким краще з системної консолі.

Тому в Linux передбачено декілька варіантів початкового завантаження, званих рівнями виконання (run levels). Рівні виконання нумеруються з 0 до 9:

• Рівень 1 відповідає розрахованому на одного користувача режиму завантаження системи. При завантаженні на рівень 1 не запускаються ніяких служб, і навіть системна консоль, як правило, буває доступна тільки одна, так що в системі може працювати не більш за одного користувача. У розрахованому на одного користувача режимі зрідка працює адміністратор - виправляє неполадки системи, змінює ключові налаштування, обслуговує файлові системи.

• Рівень 2 відповідає розрахованому на багато користувачів режиму завантаження системи з відключеною мережею. У цьому режимі не запускаються ніякі мережеві служби, що, з одного боку, відповідає строгим вимогам безпеки, а з іншого боку, дозволяє запускати служби і настроювати мережу вручну.

• Рівень 3 відповідає розрахованому на багато користувачів мережевому режиму завантаження системи. Мережа при завантаженні на цей рівень налаштована, і усі необхідні мережеві служби запушені. На цьому рівні зазвичай працюють комп'ютери-сервери.

• Рівень 5 відповідає розрахованому на багато користувачів графічному режиму завантаження системи. На цьому рівні зазвичай функціонують робочі станції, надаючи користувачам можливість працювати з графічною підсистемою XII. Мережа на цьому рівні налагоджена, а ось список запушених мережевих служб може бути менше, оскільки робоча станція не завжди виконує серверні функції (хоча, безумовно, може).

- Рівні 0 і 6 - спеціальні. Вони відповідають зупинці і перезавантаженню системи. По суті, це зручні спрощення для дій, зворотних завантаженню на рівень, : усі служби зупиняються, диски размонтуються. У разі зупинки навіть електроживлення можна відключати програмно, якщо апаратура дозволяє, а у разі перезавантаження система йде на повторне завантаження.

Інші рівні ніяк спеціально в Linux не описані, проте адміністратор може використовувати і їх, визначаючи особливий профіль роботи системи. Перехід з рівня на рівень виконується дуже просто: по команді init номер__рівня. На який рівень завантажуватися при старті системи, написано в inittab (у полі дії повинно бути написано "initdefault", а в полі рівні - тільки одна цифра). Упізнати поточний рівень виконання можна за допомогою команди runlevel.

рівень виконання

Збережений профіль завантаження системи. У Linux реалізований виконанням усіх сценаріїв зупинки і запуску служб з підкаталогу rс.рівень А каталогу /etc або /etc/red

Перехід з рівня на рівень повинен супроводжуватися не лише запуском, але і зупинкою служб. Це стосується не лише рівнів 0 і 6, але і будь-яких інших. Наприклад, при переході з рівня 3 на рівень 2 необхідно зупинити усі мережеві служби. Тому схема ".d" була розширена: спочатку з параметром "stop" запускаються сценарії, імена яких починаються на "К" (Kill), а потім, з параметром "start" - ті, імена яких починаються на "S" (Start). У наведеному прикладі при переході на рівень 2 зупиняється декілька служб, у тому числі мережевий метаде-мон (K50xinetd) і монтування по мережі видалених файлових систем (K75netfs). Якщо при переході з рівня на рівень деякій службі не вимагається міняти свого стану, сценарій не запускається зовсім. Так, при переході з рівня 3 на рівень 2 мережеві налаштування залишаються активними, тому відповідний сценарій (S10network), швидше за все, запущений не буде.

Довгий час вважалося, що визначення порядку завантаження - справа системного адміністратора, тому розставляти символьні посилання в каталогах rс.d доводилося вручну. Проте одне з іншого не виходить: можна передбачити і простіший спосіб наповнення цих каталогів посиланнями. Один із способів такий: поставити в стартовий сценарій коментар особливого виду, в якому описати, на яких рівнях служба має бути активізована, і якою по порядку має бути запущена і зупинена.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Класифікація	\|

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.021 сек.