5.4.2.2 Ідентифікатор користувача та групи

Кожен процес має UID – ідентифікаційний номер користувача, який створив даний процес. Вносити зміни до процесу можуть лише його творець та привілейований користувач (root). В процесі також є EUID – це так званий «ефективний» UID. Він використовується для того, щоби визначити, до яких ресурсів в процесі є право доступу. Зазвичай EUID та UID збігаються. Розрізнюються вони для програм, в яких установлено біт змінювання ідентифікатора користувача (так звані suid-програми).

Аналогічно, GID — ідентифікаційний номер групи користувача, котрий створив даний процес, EGID — «ефективний» GID. Коли процес запускається, його GID дорівнює GID батьківського процесу. Якщо процес спробує звернутися до файла, на який у власника немає прав доступу, ядро перевірить, чи можна дозволити звертання на підставі EGID.

5.4.3 Стани процесу в unix

Процес може перебувати в таких станах:

• виконуванний – процес перебуває в активному стані;

• очікування – процес очікує на надання певного ресурсу;

• свопований – процес перебуває в swap-розділі на диску, аналог стану очікування;

• зупинений – процес припинено, завершено.

Виконуваний процес здобув усі необхідні ресурси й очікує лише на надання часу центрального процесора для опрацьовування даних.

Процес очікування – очікує, коли надійде ресурс чи відбудеться певна подія.

Свопований процес не існує в оперативній пам’яті. Він записаний у swap-розділ на диску й очікує на «свій час» [7, 8].

Час від часу в системі виникають процеси, які у той чи інший спосіб потребýють втручання адміністратора. Такі процеси дістали назву “заблукалі”. Основні різновиди таких процесів – завислі й некеровані процеси.

Завислі процеси є бездіяльні, вони не відповідають власному керувальному терміналові, а просто «зависають», займаючи ресурси системи. Некеровані процеси бувають двох типів — користувацькі й системні. Некерований користувацький процес не обов’язково працює хибно. Просто він може «їсти» багато системних ресурсів — й через нього простоюватимуть інші, можливо, не менш корисні процеси. Некерований системний процес може (раптово “збунтувавши”) просто «трощити» все на власному шляху.

5.4.4 Керування процесами

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

Наявність двох рівнів керування процесами зумовлена пріоритетним принципом побудови ОС. На рівень довготермінового планування виносяться дії, які не часто виконуються в системі, але потребують великих системних витрат. На рівень короткотермінового планування виносяться часті й більш короткі за тривалістю дії з керування процесами.

Для знищування процесів в системі передбачено команду kill.

Формат цієї команди є kill <-сигнал> pid, де <-сигнал> — номер чи символьне ім’я сигналу, котрий надсилається процесові. Команду kill найчастіше використовують для припинення виконання процесу. Найчастіше використовувані сигнали:

9 (KILL) – гарантоване знищення процесу;

15 (TERM) – програмне завершення процесу;

1 (HUP) – сигнал відбою. Багато системних процесів при одержанні цього сигналу перечитують свої конфігураційні файли. Взагалі рекомендується давати сигнал HUP перед надсиланням сигналу KILL.

Іноді процеси потрапляють у такі стани, що їх не можна «вбити» навіть видавши команду kill -9 pid. У цьому разі найефективніший спосіб «вбити» процес – команда reboot.

Пріоритети процесу можна змінити за допомогою команди 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. Якщо її введено без опцій, то вона подасть лише власні процеси користувача і процеси обміну з терміналом. Команда має опції:

-a – надає інформацію про всі користувацькі процеси;

-е – подає значення змінних оточення;

-h – при виведенні на PAGER (more або less) подає заголовок лістинга;

-m – сортує виведення за використовуваною пам’яттю;

-r – сортує виведення за використанням часу центрального процесора;

-x – виведення команди, не асоційоване з терміналами (тобто подаються також, приміром, і процеси-демони).

Для того щоб запустити процес у фоновому режимі, треба лише набрати & після імені команди, наприклад:

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 [7, 8].