Ініціалізація масиву даних
Ініціалізація масиву має низку підводних каменів. По-перше, у різних програмних середовищах заповнення даних масиву починається або з нульового елемента A або з першого A, де A - назва масиву.Для ініціалізації масиву зазвичай використовують «покроковий» цикл for (foreach). Заповнення масиву відбувається поступово, по одному елементу під час кожного «пробігу» циклу. У циклі for створюється локальна змінна циклу - контролю кількості проходів.
Початкове значення змінної циклу має співпадати з першим елементом масиву: A або A. Кінцеве – з числом елементів масиву.
Для організації заповнення даними двовимірного масиву необхідно вкласти один цикл у інший. Таким чином, операція проходу циклу стовпцем масиву буде виконана стільки разів, скільки є в масиві рядків.
Помилки ініціалізації
При ініціалізації система отримує дані з усіх значних пристроїв, процесів чи операторів. Запуск операційної системи є ініціалізацією даних, адже операційна система отримує відгук всіх елементів комп'ютера, включаючи оперативну пам'ять, жорсткий диск та клавіатуру. Якщо один із важливих блоків відсутній, ОС не зможе пройти ініціалізацію. Серйозною помилкою ініціалізації є і відомий синій екран смерті.Рядок ініціалізації
Для керування ініціалізацією новачки часто використовують прості звернення (наприклад, X = 5) або ручний вибір. Однак регулярну ініціалізацію потрібно і можна автоматизувати.Припустимо, що користувач комп'ютера, підключений до двох інтернет-провайдерів. Швидкість з'єднання змінюється, тому користувач постійно перемикається вручну. Це незручно і забирає багато часу. Натомість він може задати рядок ініціалізації в командному рядку:
AT+CDGCONT = 1, IP, internet.mts.ru + AT+CDGCONT = 2, IP, internet.beeline.ru.
Тепер рядок ініціалізації є для комп'ютера процесом, що управляє. Якщо інтернет МТС стає швидше, ніж «Білайн», то використовується з'єднання МТС - інакше МТС змінюється на з'єднання «Білайн».
Насправді, "чисто" описати, як комп'ютер ініціалізується, не вийде - у багатьох системах це відбувається з невеликими відмінностями, та й треба враховувати набір обладнання, передустановки та ін. Але в основному це виглядає наступним чином:
Включаємо живлення – відбувається загальне скидання логіки та процесора, процесор починає виконувати набір інструкцій, які спочатку зберігаються у ПЗУ на материнській платі. Набір можна логічно розбити на три частини:
- Power On Self Test (POST) - запускається лише один раз і одразу після включення живлення. У цьому вся тесті перевіряється апаратура наявність грубих помилок (функціонування апаратури взагалі). Одним із видимих кроків на екрані – тестування пам'яті.
- Ініціалізація – запускається щоразу, коли машина перевантажується (наприклад, коли користувач натискає Ctrl-Alt-Del) – ініціалізує всі доступні пристрої на платі та у слотах розширення (ISA, PCI, AGP).
- Третя частина – це власне BIOS (BASIC INPUT/OUTPUT SYSTEM) – базова система введення/виводу на низькому рівні. Цими функціями користуються деякі операційні системи (DOS, Windows та ін.) Зазвичай, весь BIOS розташовується на окремому чіпі, що програмується на заводі, хоча у сучасних комп'ютерах може бути перепрограмований прямо із системи. Тобто. зараз використовується Flash Memory.
Особливість існуючих BIOS в тому, що вони дуже повільні (набагато повільніше, ніж звичайна оперативна пам'ять). Тому багато систем просто копіюють весь BIOS в оперативну пам'ять.
Тест пам'яті - найбільш видима частина тесту апаратури на етапі POST. До речі, про видимість - відеоадаптер - теж апаратура, і його необхідно ініціалізувати в першу чергу - щоб користувач міг бачити процес тестування та ініціалізації пристроїв. Також необхідно встановити ще й режим (частоту оновлення, роздільну здатність) екрана. Адже відеокарти можуть бути зроблені різними фірмами, та ще й різні моделі - кому як не Біос самої картки знати досконально, як її потрібно ініціалізувати?
На кожній відеокарті є свій BIOS, який опитується на наявність при тестуванні апаратури. Спочатку системний БІОС шукає відео за стандартними адресами ISA VGA, - якщо там немає адаптера, він шукається на PCI , потім на AGP (або спочатку AGP, а потім PCI - це прописується в установках BIOS SETUP). І якщо відеобіос знайдено в одному з слотів, то управління передається на нього.
І взагалі, присутність БІОСа на різних адаптерах змушує системний БІОС віддавати їм управління - у випадку з відеоадаптером - це включення режиму і т.д., у випадку з мережевою картою - завантаження з мережі (у випадку з дисковими машинами - віддалене завантаження з мережі ) - при наявність BIOS на мережній карті та наявність жорсткого диска БІОС, наприклад, може запитати - як будемо завантажуватися - з мережі або з наявного HDD? За наявності SCSI адаптера - він повинен проініціалізувати свої пристрої (диски, CD-приводи, стрічкові накопичувачі тощо) і якщо такі знайдуться з-поміж дисків SCSI - необхідно буде підтримати int13 для того, щоб система могла звертатися до них, як до звичайним жорстким дискам. Хоча, ініціалізація SCSI пристроїв необов'язкова – наприклад, при старті, її можна відключати – якщо SCSI пристрій не є завантажувальним, це розумно.
Далі перевіряється наявність жорстких дисків (IDE) на контролері вводу-виводу, дисководів для дискет тощо подібної периферії. Перевіряється клавіатура і після успішної перевірки видається одиночний звуковий сигнал, що вказує на те, що ініціалізація пройшла успішно (якщо ні - різним поєднанням звукових сигналів BIOS сигналізує про помилки та/або повідомляє про них на екрані).
Отже, коротко можна описати так: все, крім SCSI, IDE, USB "оживає" відразу - з адаптерів виняток становить відеоадаптер, який ініціалізується навіть до перевірки пам'яті.
Далі - якщо в слотах ISA знаходяться інші пристрої, що мають свої ПЗП (з BIOS) - вони ініціалізуються на етапі перевірки зовнішніх пристроїв, потім відбувається перевірка та призначення PCI (перевірка пристроїв Plug and Play). До речі, PnP є і на адаптерах ISA.
Тільки після цього починається перевірка наявності пристроїв на шині IDE.
Тут може виникнути питання - а як бути, якщо на ISA немає відеоадаптера, а є на PCI - але ж він "оживає" відразу - не чекаючи навіть перевірки всього PCI? Просто на PCI є BIOS, що відображається у звичайний простір пам'яті, і всі VGA PCI мають ще й стандартну VGA програмну частину, що знаходиться в тих же регістрах, як і у випадку, якби це був адаптер ISA. Системний BIOS перевіряє, чи є VGA на ISA шині - якщо так, то на PCI шину і "не лізе", якщо ні - сканує PCI.
Ну, і зрештою, після ініціалізації - зчитується перший сектор першої доріжки першої головки жорсткого диска і управління передається завантажувальному сектору, який вже управляє подальшими діями (або видається повідомлення типу "NO SYSTEM TO BOOT"). Або подібним чином система вантажиться з дискети.
Систем, яка запускає всі інші процеси. Працює як демон і зазвичай має PID 1. Зазвичай (відповідно до Filesystem Hierarchy Standard) розташовується на шляху /sbin/init . Існують відмінності в організації роботи підсистеми в операційних системах, що ведуть родовід від System V і систем у стилі BSD.
Тривалий час була основною підсистемою ініціалізації в Linux, доки не була в більшості дистрибутивів замінена systemd . У Solaris 10 замість init застосовується Service Management Facility. У ряді Unix-систем застосовуються альтернативи init: Upstart, Runit, Daemontools, Launchd, Initng, OpenRC.
У процесі завантаження після ініціалізації ядра зазвичай запускається /sbin/init як перший процес користувальницького режиму , і init відповідає за подальше завантаження системи. Для цього запускаються стартові сценарії, які виконують перевірку та монтування файлових систем, запуск необхідних демонів, налаштування ядра (у тому числі завантаження модулів ядра згідно з встановленим обладнанням, налаштування IP-адрес, таблиць маршрутизації та інші завдання), запуск графічної оболонки. Основна інформація для завантаження зазвичай розміщується в /etc/inittab .
У реалізації init у стилі System V використовується поняття рівня виконання – ступеня завантаження операційної системи; у цьому випадку стартові сценарії кожного рівня розкладені за каталогами від /etc/rc0.d до /etc/rc6.d , де цифра після rc відповідає номеру рівня ініціалізації.
inittab
Приклад файлу /etc/inittab:
id:5:initdefault: si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait :/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc .d/rc 6 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 x:5:respawn:/etc/X11/prefdm -nodaemon
У першому рядку описаний термінал та його конфігурація за замовчуванням. Спочатку у цьому файлі описуються рівні ініціалізації. Потім ініціюються віртуальні консолі. Запис ініціалізації консолей складається з полів, розділених двокрапкою і виглядає так:
- 1 - порядковий номер консолі
- 2345 – номери рівнів ініціалізації, для яких консоль ініціалізується
- respawn - цей параметр означає, що init повинен перезапустити обслуговуючий консоль процес після виходу із сеансу або у разі краху.
- /sbin/mingetty tty6 - програма (із зазначенням параметрів), яка обслуговуватиме консоль.
Таким чином, ви можете легко створити свій рівень ініціалізації (під номером 4 або 7, 8…), просто виправивши файл /etc/inittab і створивши необхідні посилання в каталозі /etc/rc.d/rc*.d .
SysVinit
У порівнянні з його попередниками, AT&T UNIX System III представив новий стиль конфігурації запуску системи, який зберігся (зі змінами) в UNIX System V і тому називається « SysVinit ».
У будь-який момент працююча система V знаходиться в одному із заздалегідь визначених станів, званих runlevel. Принаймні, один рівень виконання є нормальним робочим станом системи; як правило, інші рівні виконання становлять однокористувацький режим (використовується для відновлення несправної системи), вимкнення системи та різні інші стани. Перемикання з одного рівня виконання на інший викликає запуск набору сценаріїв для кожного рівня запуску, які зазвичай монтують файлові системи, запускають або зупиняють daemon, почати або зупинити X Window System, вимкнення машини і т.д.
І змішав усі карти. Але хто ж був справжнім першопрохідником?
Daniel J. Bernstein математик і фахівець з криптографії, автор популярного MTA qmail та безлічі інших менш відомих програм, серед яких виділяється daemontools. Для багатьох сучасних систем ініціалізації daemontoolsбув прикладом та натхненником. Прошу всередину для того, щоб познайомитися з найелегантнішою, найпростішою і найвпливовішою системою управління службами в Unix/Linux.
DJB та Daemontools
Максвелла для управління процесами на Unix ОС.
Увага - не слід плутати daemontoolsнаписаний DJB із програмою-тезкою DAEMON Tools для монтування iso образів та створення віртуальних CD/DVD дисків.
Daniel J. Bernstein створив свою програму у 1997 р. Останній стабільний реліз був у липні 2001 р.
Зараз, коли в Linux співтоваристві спостерігається розкол через systemd, саме час згадати яким може бути справжній ініт у дусі принципів та філософії Unix. У цьому сенсі дзен-програміст DJB є втіленням мінімалізму та простоти, а бритва Оккама у нього вбудована у клавіатуру. Його рішення ґрунтовні та елегантні, на цьому фундаменті він будує надійне, безпечне ПЗ, яке споживає мінімальну кількість ресурсів ОС. Ось деякі особливості його стиль роботи.
- Найбільший файс вихідного коду multilog.c має лише 13898, немає не рядків, а байтів. Команда wc вказує лише на 617 рядків коду.
- Більшість функцій має менше 30 рядків.
- Принцип – ніколи нічого не псувати.
- Принцип – використовувати все, що дає ОС і не винаходити велосипеди.
Чому такі дивні принципи, і ще з огляду на те, що автор сповідує їх фанатично? Будівельний матеріал daemontools- директорії, процеси, FIFO, файли, що виконуються. Це дає масу переваг у розробці та налагодженні програми:
- Тестувати запуск служби простіше простого - якщо запуститься виконуваний файл./run, то служба теж запуститься.
- Можна використовувати будь-яку мову програмування, не лише Bash. Пригодиться навіть скомпільований бінарник.
- Зрозуміло, що і як програма робить навіть без докладного прочитання документації та вивчення вихідного коду.
- Парсити різноманітні текстові структури - напрочуд важке завдання, якщо це робити з розуму. Автор уникає цього, вміло використовуючи ієрархічну властивість файлової системи Unix для відтворення структури змінних середовища ключ = значення.
Порівняльна таблиця DT
Варто звернути увагу на неортодоксальну структуру директорій daemontools, анітрохи не вагаючись програма створює каталоги в корені файлової системи Unix. DJB прописав у коді програми директорії /service, /command і рекомендує створити /package для вихідних програм. Це вважається дуже поганим тоном в Unix і Linux, творці дистрибутивів усіма силами уникають цього, як і користувачі з правами root.
| features | inittab | ttys | init.d | rc.local | /service |
|---|---|---|---|---|---|
| Easy service installation and removal | No | No | Yes | No | Yes |
| Easy first-time service startup | No | No | No | No | Yes |
| Reliable restarts | Yes | Yes | No | No | Yes |
| Easy, reliable signalling | No | No | No | No | Yes |
| Clean process state | Yes | Yes | No | No | Yes |
| Portability | No | No | No | No | Yes |
Давайте пробіжимося по таблиці самовихваляння daemontools. Почнемо з першого рядка. Справді створення та видалення нового сервісу простіше простого, додав, або видалив нову директорію в /service разом із файлом./run і на цьому все. Порівняйте зі скриптами sysvinit та інших інітів, щоб оцінити простоту такого способу досягти того самого.
Другий пункт менш переконливий у тому сенсі, що звичайно простіше коли сервіс і вперше стартує автоматично, але в інших системах ініціалізації та управління службами достатньо однієї команди для першого старту служби.
Можливість перезапустити сервіс, що завершився, в автоматичному режимі була на той момент великим кроком вперед. На сьогодні це вже гаразд.
Четверта позиція – сигнали. Команда svc , як показано нижче, дозволяє надіслати службі практично будь-який сигнал стандарту POSIX.
Останні дві позиції здаються дещо надуманими, не зовсім зрозуміло як daemontoolsвідновлює стан процесу на відміну інших інітів. Незрозуміло також, чому автор лише свою програму вважає, що переноситься на інші платформи.
Структура DT
За словами автора: daemontools- це набір інструментів для керування службами UNIX. Основними відмінностями від традиційних інітів (структури директорій rcX.d, rc.d, rc.local та ін.) є здатність перезапустити сервіс у разі його падіння та наявність програми ведення та ротації логів – multilog. Також, multilog дозволяє вести лог виведення програм, які не вміють перенаправляти виведення в syslog. Таким чином можна запускати як сервіс програми, для цього зовсім не призначені.
Внутрішній пристрій daemontools, межа обведена червоною уривчастою лінією.
Тепер трохи про засади роботи програми.
На самому початку системний ініт запускає svscanboot, який потім запускає програму svscan у новоствореній директорії svscan. Далі svscanboot перенаправляє виведення запущеного svscan в налагоджувальний процес readproctitle .
Ядром daemontoolsЄ лише дві програми: svscan і supervise . Перша запускається з єдиним аргументом на вибір, а друга - з обов'язковим ключем.
Svscanслужить для запуску та стеження за сервісами. Кожні 5 секунд Svscan перевіряє каталог /service, якщо інший не заданий, на наявність нових підкаталогів. Якщо таке буде виявлено, запускається нова копія supervise для кожного каталогу.
Superviseє, відповідно до назви, що контролює процесом. Він викликається з параметром, в якому міститься ім'я каталогу і шукає скрипт./run , який і запускає. Якщо з якихось причин./run перестав виконуватися, то тоді supervise його перезапустить після невеликої паузи – щоб не створювати додаткового навантаження на ОС. Supervise не перезапустить./run, якщо в каталозі буде виявлено файл./down. Supervise створює у каталозі сервісу подкаталог./supervise , у якому зберігаються дані процес. Ці дані можуть бути прочитані за допомогою утиліти svstat. Для управління сервісом служить програма svc.
Синтаксис команди svc та опції представлені нижче.
svc options services
- -u: Up, запустити сервіс, у разі зупинки – перезапустити.
- -D: Down, зупинити сервіс.
- -t: Terminate, що посилає сервісу сигнал TERM.
- -k: Kill, посилає сервісу сигнал KILL.
- -p: Pause, що посилає сервісу сигнал STOP.
- -c: Continue, що посилає сервісу сигнал CONT.
- -h: Hangup, що посилає сервісу сигнал HUP.
- -a: Alarm, що посилає сервісу сигнал ALRM.
- -h: Interrupt, що посилає сервісу сигнал INT.
- -x: Exit, supervise завершить роботу як тільки./run або його нащадок завершиться.
- -o: Once, запустити сервіс, але не перезапускати після завершення.
Є ще одна обставина, якщо в робочому каталозі supervise міститься підкаталог./log, в якому є./log/run, тоді буде запущена ще одна копія supervise і створено канал між./run і./log/run.
Спробуймо додати сервіс sshd.
#!/bin/sh # перенаправити stderr до stdout exec 2>&1 # з опцією -D sshd виконується явно, з опцією -e налагодження пишеться в stderr exec /usr/sbin/sshd -D -e
У такому разі структура директорій може мати такий вигляд.
- service/ |- ngetty/ | |- run | |- log/ | |- run |- sshd/ | |- run | |- log/ | |- run |- squid/ | |- run | |- log/ | |- run
Після того, як svscan пробіжиться цим списком ми отримаємо дерево процесів, в якому процеси service стежать за сервісами та логуванням.
-svscan-+-service-+-ngetty | `-log-service +-service-+-sshd | `-log-service +-service-+-crond | `-log-service
Залежності між службами
Незважаючи на те, що програма не підтримує залежності між різними службами, є спосіб домогтися обліку залежностей, використовуючи для цього svok наступним чином.
#!/bin/sh svok postgres || (echo "waiting for postgres..." && exit 1) exec 2>&1 exec python3 your-web-app.py
- svok – перевіряє, чи запущена певна служба. Нічого не виводить у stdout і stderr , якщо служба запущена, тоді програма повертає код 0, інакше - код 100.
В даному прикладі програма на python запуститься тільки в тому випадку, якщо стартував postgres, якщо ж останній поки не піднявся, скрипт завершиться і потім через певний час svscan його перезапустить. Коли postgres нарешті підніметься, python запустить веб додаток.
Квотування сервісу
За допомогою утиліти softlimit можна обмежити надані сервісу ресурси.
#!/bin/sh exec 2>&1 # змінити користувача на foo, обмежити стек 4096 байтами, відкриті # файлові дескриптори 15 та кількість процесів 1: exec setuidgid foo softlimit -n 4096 -o 15 -p 1 \ bar -n
- softlimit – запускає програму з ресурсними обмеженнями.
Логування
Якщо у вас є якась програма foo, яка не веде логів, ви легко зробите це за допомогою multilog, зібравши в окремому файлі висновок stdout і stderr з тимчасовими мітками.
Після завершення завантаження ядра, забезпеченням якого ми займалися в минулому update, настає час ініціалізації системи. Вона починається запуском процесу init, що здійснюється виконанням однойменного файлу /sbin/init. Розглянемо його штатні завдання.
Першою з завдань, як у часі виконання, і за значенням, є перевірка цілісності готівкових файлових систем. Спочатку кожна з них перевіряється на наявність біта "чистого розмонтування" (clean byte), який автоматично встановлюється в ході правильного завершення попереднього сеансу роботи. Якщо такий біт виявляється на кожній файловій системі — все гаразд, справа рухається далі. Якщо ні, запускається примусова перевірка некоректно розмонтованої файлової системи.
Слід зазначити, що сам по собі "біт чистого розмонтування" не гарантує збереження файлової системи і, особливо, її даних. Він лише показує, що файлова система була коректно розмонтована на попередньому сеансі. У цьому випадку процес init робить не позбавлене резону припущення, що з метаданими та даними її все гаразд, і переходить до виконання наступного завдання. Втім, при загальноприйнятому нині використанні файлових систем біт "чистого розмонтування" присутній завжди.
А наступне завдання процесу init – це виклик та відпрацювання сценаріїв ініціалізації, або стартових скриптів, зібраних у каталозі /etc та його підкаталогах. Це звичайні сценарії оболонки, розраховані виконання стандартним шеллом (в Linux - /bin/bash). Вони включають послідовності команд, покликані монтувати файлові системи, активізувати область свопінгу, встановлювати системний годинник, запускати ті чи інші служби і демони, включаючи мережеві з'єднання.
Команди, що утворюють стартові сценарії, отримують свої опції, їх значення та аргументи зі спеціальних файлів конфігурації, що також мають своїм місцезнаходженням /etc та його підкаталоги. Конфігураційні файли (або по простому конфігі) є або найпростіші бази даних опцій і аргументів команд, або списки імен змінних, (відповідних опціям команд, що використовуються в скриптах) з наданими їм значеннями. Конфіги від скриптів легко відрізняються при перегляді каталогу /etc відсутністю перших біта виконання.
Наприклад, обов'язкова процедура на стадії відпрацювання сценаріїв ініціалізації - монтування (і перемонтування) необхідних файлових систем в режимі читання/запису - адже, як ми пам'ятаємо з попереднього розділу, при завантаженні ядра коренева файлова система, що несе його, монтується в режимі "тільки для читання". Це виконується прямою директивою
# /sbin/mount -a наказує змонтувати всі файлові системи, і входить до складу одного зі стартових сценаріїв. В якій саме залежить від системи, і з часом ми розберемося, де вона знаходиться в нашому випадку). А ось що розуміється під словом "все" (ім'я опції -a - від all) - тобто список аргументів (пристроїв і точок монтування), а також опцій, з якими має бути змонтована та чи інша файлова система, - і становить зміст конфігураційного файлу /etc/fstab.
Це — дуже проста база даних, кожен запис якої відповідає файловій системі, що підлягає монтуванню, а поля, роздільником яких є символи пробілу (пробілів) або табуляції, наступні:
- ім'я файлу пристрою, що несе файлову систему;
- точка монтування - каталог у файловій ієрархії;
- тип файлової системи;
- опції монтування (часто має значення default).
Послідовне поділ стартових сценаріїв та його конфігураційних файлів - одне із наріжних принципів загальносистемного конфігурування. По суті, користувачеві при нормальному ході налаштування практично немає необхідності ні знайомитися з вмістом скриптів (хоча це і не шкідливо), ні, тим більше, міняти в них що-небудь (останнє допустимо тільки в тому випадку, якщо цей користувач точно знає, що робить, інакше систему легко довести до непрацездатного стану). А ось вносити зміни до значення параметрів конфігураційних файлів - не тільки можна, але і потрібно, причому, як ми скоро побачимо, у різний спосіб. Зрозуміло, такий дозвіл не позбавляє користувача розуміння сенсу своїх дій.
Нарешті, третє неодмінне завдання процесу init — забезпечення реєстрації користувача у системі, яка також може здійснюватися різними способами: у текстовій консолі чи через графічні менеджери сеансів.
Описана послідовність ініціалізації відбувається при беззбійному її протіканні - якщо на жодній із стадій не відбувається помилок. Найсерйозніші наслідки матимуть помилки при монтуванні файлових систем, звичайне джерело яких — неправильний опис у файлі /etc/fstab (тобто елементарні друкарські помилки) або відсутність підтримки ядром (або його модулем) типу файлової системи, що несе корінь файлового дерева. У разі ядро впаде в паніку (т.зв. Kernel panic) і продовження завантаження виявиться неможливим.
Помилки при відпрацюванні скриптів ініціалізації зазвичай призводять до того, що сервіс, при виконанні сценарію запуску якого стався збій, просто не буде доступним після завантаження системи.
Нарешті, помилки під час підготовки до реєстрації також досить неприємні, і, зазвичай, призводять до неможливості початку нормальної роботи.
Втім, підстав для паніки немає в жодному із зазначених випадків — навіть у разі впадання в паніку ядра. Всі можливі при ініціалізації системи помилки можна виправити тим чи іншим способом. Бо легкий флірт, у тому числі і з операційною системою, подібно до нежиті, переноситься на ногах, і постільний режим необхідний лише у важких випадках. В одних ситуаціях достатньо завершити процес завантаження і трохи змінити налаштування, в інших - завантажитися в режимі одного користувача, в третіх доведеться завантажуватися з rescue-носія (наприклад, LiveCD). А ось хірургічного втручання, або повної переустановки системи, швидше за все, не потрібно ніколи.
Зворотний бік ініціалізації системи - це її зупинка або рестарт, відмінностей між цими процесами практично немає. І відповідає за нього команда shutdown, яка може бути дана від імені суперкористувача або члена групи operator. З опцією -h вона викликає зупинку машини, з опцією -r - її перезавантаження. І ще цій команді потрібен аргумент - час, коли зупинка або рестарт мають статися. Втім, є спосіб і миттєвого зупину або рестарту:
# shutdown -h now або # shutdown -r now відповідно. Саме остання команда відпрацьовується при перезавантаженні машини з клавіатури за допомогою "Салюту з трьох пальців", за словами Патріка Фолькердінга.
Крім того, існують також команди halt та reboot того ж призначення. Проте самостійної ролі вони не грають, просто викликаючи команду shutdown з опцією зупинки та перезавантаження відповідно.
Зупинка системи відбувається у порядку, зворотному її ініціалізації. Спочатку робиться спроба коректного завершення всіх запущених додатків, а за неможливості такої - їхнє примусове завершення. Потім стопоряться всі стартові сервіси та демони. Нарешті вміст дискових кешів записується на диск, і розмонтуються файлові системи. Після цього зазвичай з'являється повідомлення про можливість безпечного відключення живлення машини або воно автоматично вимикається. При рестарті все відбувається так само, але після зупинки системи автоматично починається перезавантаження машини. Весь процес зупинки та (або) рестарту визначається сценаріями, подібними до сценаріїв ініціалізації.
Протягом багатьох років одним із перших правил техніки безпеки була заборона зупиняти простим відключенням живлення. І справді, донедавна це було чревато різними неприємностями.
Однак у сучасному ядрі Linux реалізовано підтримку управління живленням стандарту ACPI (Advanced Configuration and Power Interface). Вона робить припустиме зупинення системи простим відключенням живлення машини - на натискання кнопки Power на корпусі комп'ютера (але в жодному разі не на перемикання тумблера блоку живлення або висмикування силового кабелю) система реагує так само, як і на команду shutdown -h now. Зокрема, в Zenwalk'е ця процедура виконується абсолютно безболісно. Зрозуміло, на більш-менш сучасному "залізі".
Для розуміння процесу ініціалізації системи дуже важливим є поняття runlevels. Це один з тих термінів, будь-який російський переклад якого здатний тільки збити з пантелику початківця користувача. Тому що часто використовуються переклади типу рівні запускуабо рівні завантаженняСтворюють враження, що у процесі ініціалізації послідовно проходить деякі, відповідні їм, стадії. Насправді це набори тих сценаріїв, про які ми говорили вище, і які виконуються в тій чи іншій ситуації.
Виклик певного runlevel, тобто така взаємопов'язана група сценаріїв, здійснюється при ініціалізації системи програмою /sbin/init. А самі ці групи описані в основному конфігураційному файлі - /etc/inittab , що описує весь хід процесу init - від перевірки файлових систем до підготовки до реєстрації.
Теоретично процес init передбачає виклик семи runlevels— від нульового до шостого, хоч, здається, в жодному дистрибутиві вони не задіяні всі. За трьома з них зафіксовано групи сценаріїв певного призначення:
- 0 - halt, тобто зупинка системи;
- 1 - single user mode, або однокористувацький режим;
У ньому після всякого роду копірайтів для початку перераховуються всі runlevels і пояснюється їх значення для дистрибутива Slackware, оскільки в Zenwalk'е, його прямому нащадку, вони відрізняються лише в деталях. Так що ось на цих деталях ми і загостримо увагу:
- 0 = зупинка системи;
- 1 = однокористувацький режим;
- 2 = не використовується, але налаштований аналогічно runlevel 3;
- 3 = розрахований на багато користувачів текстовий режим;
- 4 = розрахований на багато користувачів графічний режим з авторизацією через менеджер сесій GDM;
- 5 = не використовується, але налаштований аналогічно runlevel 3;
ідентифікатор: runlevel: дія: процес, що запускається
Не у всіх рядках значення присвоєно кожному полю.
Для початку визначається рівнемрівень за замовчуванням. У Zenwalk"е, на відміну від Slackware, "замовчальним" рівнем за замовчуванням є 4-й, що описується таким рядком:
Id:4:initdefault: Якщо необхідно перейти на завантаження в текстовому режимі (це може статися при збоях графічної системи), її слід замінити рядком id:3:initdefault: Далі слідує серія рядків, що описують, які сценарії повинні запускатися при кожному з задіяних runlevels та деякі інші події, як то:
- старт системи (виконується в будь-якому випадку, незалежно від рівнярівня за замовчуванням);
- завантаженні в однокористувальному режимі або переході в нього з будь-якого розрахованого на багато користувачів;
- завантаженні в будь-якому з розрахованих на багато користувачів режимів;
- "комбінації з трьох пальців" (Three Finger Salute, за висловом Патріка Фолькрдінга);
- звичайному зупиненні системи;
- звичайному програмному перезавантаженню;
- аварійне відключення живлення;
- відновлення харчування після збою.
А поки що, слову скажу, що перехід з одного runlevels на інший здійснюється командою
# /sbin/init # де # - необхідний runlevel. Наприклад: # /sbin/init 0 викличе зупинення системи, аналогічно команді # shutdown -h now команда # /sbin/init 6 її перезавантаження, як при команді # shutdown -r now а команда # /sbin/init 1 перехід в однокористувацький режим - ситуація, якої практично іноді доводиться вдаватися. Втім, це не якась особливість Zenwalk, а загальна властивість всіх Linux-систем.
c1:1235:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 t3 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Таких за замовчуванням шість. Чому "як би" - зараз побачимо: у полі runlevels всіх рядків перераховані всі доступні користувачам рівні, і лише в першій з них пропущений runlevel 4. А саме він є замовчальним у Zenwalk"і. Це викликано тим, що перший віртуальний термінал зарезервований для запуску X-сервера та менеджера сесій, так що у звичайному житті користувачеві доступні лише 5 віртуальних терміналів.
Втім, оскільки Zenwalk орієнтований працювати у графічному режимі, цього цілком достатньо. Більше того, кількість віртуальних терміналів можна скоротити: для цього достатньо закрити коментарями відповідні рядки.
При необхідності ніхто не забороняє і збільшити кількість консолей: для цього достатньо додати потрібну кількість рядків, не забувши змінити їх ідентифікатори.
Ще звернемо увагу на поле дії: значення respawn, що означає автоматичне перезапуск процесу у разі його завершення. Тобто: після завершення сеансу користувача на будь-якій консолі відразу з'являється запрошення до авторизації.
Останній рядок визначає сценарій під час запуску графічного режиму:
X1:45:respawn:/etc/rc.d/rc.4 Можна бачити, що він присвячений рівням 4 і 5, а також тягне за собою "відновлення" після завершення сеансу.
У цьому розгляд ініціалізації системи вважатимуться закінченим. Якщо чогось упустив — буду вдячний на вказівку прогалин. Додам лише, що це питання докладно висвітлено у статті Володимира Попова Init et cetera або Про стилі завантаження Linux. Дата її бентежити не повинна - нічого принципово нового в дистрибутивах, які не використовують upstart або initng, не змінилося.
