2 Порядок виконання роботи
1 Студент може працювати як за машиною під керуванням Unix, так і за машиною під керуванням OC Windows (у цьому разі студент підмикається до Unix машини, використовуючи telnet).
2 Після підімкнення студент вводить ім’я (login) і пароль (password).
3 Виконати прості команди, після введення кожної команди потрібно натиснути клавішу <Enter>:
cd / ; перейти до кореневого каталога
ls –all ; перегляд повного вмісту каталога
ls –FA; перегляд скороченого вмісту каталога, з позначенням файлів, програм, директорій
cd /tmp; перехід до тимчасового каталога
mkdir st*; створення теки st* (* — номер комп’ютера)
ee text*; створення текстового файла й написання в ньому будь-якого тексту, для виходу з редактора — натиснути Esc+Enter (* — номер комп’ютера)
ls –FA;
mv text* new_text*; перейменування файла
mv new_text* /tmp/st*/; перенесення файла у /tmp/st*/
cd st*/
ls ; скорочений перегляд поточного каталога
file new_text* ; перегляд типу файла
cat new_text* ; перегляд вмісту файла
cd .. ; перехід до попереднього каталога
rm -r st*/ ; вилучення теки з файлами
ls –FA ; переконаймося у відсутності теки
4 За допомогою програми telnet підімкніться до сусіднього комп’ютера, адреси комп’ютера, login, password зазначає викладач (наприклад: telnet 192.168.1.41).
Послідовно наберіть команди:
mail st*; напишемо лист собі
Subject: пошта; тема листа
Текст листа: Перевірка
Ctrl+d; вихід із програми
mail; одержання листа
Самостійно напишіть листа сусідові по бригаді та прийміть листи від усіх користувачів у групі.
3 Контрольні питання
1 Основні причини популярності UNIX.
2 Модель системи UNIX. Принцип дії.
3 Внутрішня структура ядра UNIX.
4 Функції файлової підсистеми.
5 Що контролює підсистема керування процесами?
6 Що забезпечує підсистема введення/виведення?
Лабораторна робота № 5 керування процесами
Мета: ознайомитись з процесами й набуття навичок з керування процесами в ОС UNIX.
Тривалість роботи – 2 години
1 Основні теоретичні відомості
Поняття процесу
В літературі з тематики операційних систем поняття «процес» є базовим і водночас найменш точно означеним. Існує безліч означень як формального, так і неформального характеру, неоднозначність в означенні є зрозуміла. Поняття «процес» є певним різновидом абстракції, котрий по-різному використовують, а також і розтлумачують по-різному. Приміром, точки зору прикладних і системних програмістів щодо цього розходяться в деталях, у формах сприйняття й реалізації цього поняття.
Є всі підстави стверджувати, що архітектура сучасної багатопрограмної ЕОМ є багатопроцесорна. Насправді, процесор — це будь-який пристрій у складі ЕОМ, здатний автоматично виконувати припустимі для нього дії в певному обумовленому порядку, тобто за програмою, збереженою в пам’яті і безпосередньо доступною такому активному пристроєві. Тоді, окрім центрального процесора (одного чи декількох), можна назвати процесором канал та пристрій, який працює з каналом. У даному тлумаченні оператор також підпадає під означення процесора. Поміж процесорами в системі існують інформаційні й керувальні зв’язки.
Кожен процесор — це такий об’єкт у системі, яким, у загальному випадку, бажали б скористатися водночас декілька користувачів для виконання своєї програми на процесорі (йдеться не обов’язково про центральний процесор). Стосовно кожного користувача, котрий претендує на виконання програми на певному процесорі, й системи, яка розподіляє цей процесор з-посеред багатьох користувачів, впроваджується поняття «процес». У загальному випадку процес— це певна діяльність, пов’язана з виконанням програми на процесорі.
Процес – фундаментальне поняття операційних систем сімейства UNIX. За допомогою керування процесами відбувається керування ресурсами комп’ютера, використовуваними для виконання програми. Вам може здаватись, що в UNIX усе виконується одночасно, однак насправді в певну одиницю часу виконується лише один процес. Ілюзію паралельного виконання створює метод «квантування часу», за допомогою якого система через певні проміжки часу (10...20 мс) змінює поточний виконуваний процес.
Системний адміністратор може контролювати стан процесу, керувати наданням часу центрального процесора кожному процесові, припиняти й примусово завершувати виконання процесу.
Компоненти процесу
Кожен процес складається з адресного простору й набору структур даних, які містяться в ядрі системи. До найбільш важливих даних у структурах належать:
таблиця розподілу пам’яті процесу;
поточний статус процесу;
пріоритет виконання процесу;
інформація про ресурси системи, використовувані процесом;
власник процесу.
Ідентифікатор процесу
Кожному новому процесові привласнюється унікальний номер — PID. Фактичне значення PID особливої ролі не відіграє: номери призначаються ядром просто один за одним, розпочинаючи з 0 й завершуючи 65535. Коли номери закінчуються, ядро розпочинає знову з 0, пропускаючи процеси, які ще існують в PID.
Ідентифікатор батьківського процесу
Новий процес в UNIX утворюється шляхом клонування одного з існуючих процесів, після чого текст (тобто набір інструкцій для процесора) нового процесу замінюється на текст програми, котру цей процес має виконати. В UNIX вихідний процес називають батьківським, а його клон – породженим, або дочірнім.
Окрім власного ідентифікатора PID, кожен процес має атрибут свого батьківського процесу – PPID.
Ідентифікатор користувача і групи
Кожен процес має UID – ідентифікаційний номер користувача, який створив даний процес. Вносити зміни в процес можуть лише його творець та привілейований користувач (root). В процесі також є EUID – це так званий «ефективний» UID. Він використовується для того, щоби визначити, до яких ресурсів в процесі є право доступу. Зазвичай EUID та UID збігаються. Розрізнюються вони для програм, в яких установлено біт зміни ідентифікатора користувача (так звані suid-програми).
Аналогічно, GID — ідентифікаційний номер групи користувача, котрий створив даний процес, EGID — «ефективний» GID. Коли процес запускається, його GID дорівнює GID батьківського процесу. Якщо процес спробує звернутися до файла, на який у власника немає прав доступу, ядро перевірить, чи можна дозволити звертання на підставі EGID.
Стан процесу, "заблукалі" процеси
При виконанні програм на центральному процесорі найчастіше розрізнюють такі характерні окремі стани:
породження — підготовлюються умови для першого виконання на процесорі;
активний стан, чи стан «Рахунок» — програма виконується на процесорі;
очікування — програма не виконується на процесорі через зайнятість певного необхідного ресурсу;
готовність — програма не виконується, але для виконання надано всі необхідні в даний момент ресурси, окрім центрального процесора;
завершення — нормальне чи аварійне завершення виконання програми, після якого процесор й інші ресурси їй не надаються.
Іноді використовують менш детальне подання станів процесу, відмінне від наведеного. Сам факт існування процесу не надає йому права на одержання часу центрального процесора.
Процес перебуває в кожнім зі своїх припустимих станів впродовж певного часу, після чого переходить у якийсь інший припустимий стан. Склад припустимих станів, а також припустимі переходи зі стану в стан зазвичай задають у формі графа існування процесу, приклад якого наведено на рис. 2.1.
В ОС FreeBSD використовується також інша термінологія. Процес може перебувати в таких станах:
здійснéнний — процес перебуває в активному стані;
очікування — процес очікує на надання певного ресурсу;
свопований — процес перебуває в swap-розділі на диску, аналог стану очікування;
зупинений — процес припинено, завершено.
Здійснéнний процес здобув усі необхідні ресурси й очікує лише на надання часу центрального процесора для опрацювання даних.
Процес очікування — очікує, коли надійде ресурс чи відбудеться певна подія.
Свопований процес не існує в оперативній пам’яті. Він записаний у swap-розділ на диску й очікує на «свій час».
Рисунок 5.1 — Граф існування процесу
Час від часу в системі виникають процеси, які у той чи інший спосіб потребýють втручання адміністратора. Такі процеси дістали назву “заблукалі”. Основні різновиди таких процесів — завислі й некеровані процеси. Завислі процеси є бездіяльні, вони не відповідають своєму керувальному терміналові, а просто «висять», займаючи ресурси системи. Некеровані процеси бувають двох типів — користувацькі й системні. Некерований користувацький процес не обов’язково працює неправильно. Просто він може «їсти» багато системних ресурсів — й через нього простоюватимуть інші, можливо, не менш корисні процеси. Некерований системний процес може (раптово “збунтувавши”) просто «трощити» все на своєму шляху.
Управління процесами, команди kill та nice
Дворівнева схема керування процесами
При побудові системи керування процесами в більшості сучасних операційних систем використовують дворівневу схему. Це означає, що в системі розрізнюють два види планувальників процесів, котрі виконують відповідно функції довгострокового й короткострокового планування щодо використання центрального процесора для розвинення на ньому великої кількості процесів. Ці планувальники мають різні назви в різних операційних системах і становлять у сукупності з певними інформаційними структурами в кожній з них систему керування процесами.
Наявність двох рівнів керування процесами зумовлена пріоритетним принципом побудови ОС. На рівень довгострокового планування виносяться дії, які не часто виконуються в системі, але потребують великих системних витрат. На рівень короткострокового планування виносяться частини й більш короткі за тривалістю дії з керування процесами.
Команда kill
Для знищення процесів в системі передбачено команду kill.
Формат цієї команди є kill <-сигнал> pid, де <-сигнал> — номер або символьне ім’я сигналу, котрий надсилається процесові. Команду kill найчастіше використовують для припинення виконання процесу. Найчастіше використовувані сигнали:
9 (KILL) — гарантоване знищення процесу;
15 (TERM) — програмне завершення процесу;
1 (HUP) — сигнал відбою. Багато системних процесів при одержанні цього сигналу перечитують свої конфігураційні файли. Взагалі рекомендується давати сигнал HUP перед надсиланням сигналу KILL.
Іноді процеси потрапляють у такі стани, що їх не можна «вбити» навіть видавши команду kill -9 pid. У цьому разі найефективніший спосіб «вбити» процес – команда reboot.
Команда nice
Пріоритети процесу можна змінити за допомогою команди nice. Від пріоритету процесу залежить, яку частину часу центрального процесора він одержить. Обираючи процес для виконання, ядро відшукує процес з найвищим «внутрішнім пріоритетом». Безпосередньо змінити значення внутрішнього пріоритету неможливо, але можна вплинути на нього, змінюючи так зване nice-значення.
Для цієї мети використовується команда nice. Формат цієї команди:
nice <відносний пріоритет від процесу-батька> <команда>. Відносний пріоритет у системі FreeBSD перебуває у межах від –20 до +20.
Важливо запам’ятати: чим нижче значення nice — тим вище пріоритет процесу.
Приклад:
nice –10 /usr/local/mygame
Якщо користувач не вживе надзвичайних заходів, то новий процес “успадкує” пріоритет свого “батька”. Користувач може збільшити значення nice (тобто знизити пріоритет), але не зможе зменшити його, навіть для повернення процесу до пріоритету, наданого при «народженні».
Привілейований користувач може змінювати пріоритети процесів як завгодно, аж до того, що всі процеси, окрім одного, не зможуть працювати.
У системі FreeBSD існує команда renice, за допомогою якої можна змінити пріоритет уже запущеного процесу. Її формат:
renice <пріоритет> [-p pid] [-g <група>] [-u <користувач>] Приклад:
renice +1 -p 989 -u daemon root -p 32
У прикладі знижується на одиницю пріоритет процесів з номерами PID 989 і 32, а так само у всіх процесів, власниками яких є daemon та root.
Поточний контроль процесів, команди ps та top
Для поточного контролю стану процесів у системі використовується команда ps.
Якщо її введено без опцій, то вона покаже лише власні процеси користувача і процеси обміну з терміналом. Команда має опції:
-a — видає інформацію про всі користувацькі процеси;
-е — показує значення змінних оточення;
-h — при виведенні на PAGER (more або less) подає заголовок лістинга;
-m — сортує виведення за використовуваною пам’яттю;
-r — сортує виведення за використанням часу центрального процесора;
-x — виведення команди, не асоційоване з терміналами (тобто показуються також, приміром, і процеси-демони).
Наберіть команду
ps –ax
Погляньмо на лістинг (тут подано задля стислості лише один рядок, окрім заголовка, й лише частина полів):
USER PID STAT START TIME COMMAND
bob 1167 R+ 5:57PM 0:00.04 ps –ax
USER — ім'я власника процесу
PID — ідентифікатор процесу
STAT — поточний статус процесу
R = здійснéнний, T = зупинений
I = той, що очікує, S = той, що очікує (> 20 с)
Z = зомбі
Додаткові прапорці:
W = процес своповано
+ = процес у пріоритетному режимі свого терміналу
START — час запускання процесу
TIME — час центрального процесора, “спожитий” процесом
COMMAND — ім’я й аргументи команди
Для самостійного вивчення вам подається команда top. Виведення цієї команди є аналогічне до виведення команди ps.
Використання команди top — вельми дороге задоволення, тому що вона сама «використовує» доволі багато ресурсів системи. Не варто нею зловживати.
Захист фонових процесів, команда nohup
Для того щоб запустити процес у фоновому режимі, потрібно просто набрати & після імені команди, наприклад:
cat /var/log/messages | grep fetchmail > fetchmail.log &
Але якщо, приміром, використовувати в якості shell інтерпретатор sh і відразу ж після цієї команди вийти із системи командою exit (чи Ctrl+D), інтерпретатор надсилає сигнал відбою (HUP) цьому процесові (як, проте, й усім, ним породженим). Для того, аби цього не відбулося, слід запустити цю команду за допомогою команди nohup.
nohup cat /var/log/messages | grep fetchmail > fetchmail.log &
У цьому разі сигнал відбою від sh буде зігноровано. У команди nohup є побічні ефекти: вона збільшує значення nice на +5. Якщо стандартний файл виведення не перепризначено, тоді все виведення піде у файл nohup.out (у нашому випадку цього не станеться); теж ж саме стосується і стандартного файла помилок. Якщо користуватися csh чи іншими сучасними інтерпретаторами, то можна обходитися без команди nohup.
Щоби перервати процес за вказаним ім’ям, треба використовувати команду killall.