CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
20.11.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Desktop
Internet
Internet-серверы
Безопасность
Бизнес/Офис
Игры
Мультимедиа
Наука
Операционные системы
Программирование
СУБД
Создание веб-сайтов
Утилиты

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дистрибутивы :: BSD :: FreeBSD

Мир на трёх кашалотах мается
1. Процессы

CITKIT.ru

Страницы: предыдущая :: 1 :: 2 :: 3

Содержание

Жизнь и смерть процесса

Каждый пользовательский процесс порождается каким-либо другим процессом — в конечном счете, в первооснове их всех лежит процесс init. Как нетрудно догадаться, порождающий процесс называется также родительским, или материнским (parent), а порожденный — дочерним (child). И идентификатор родительского процесса (PPID) — также один из важных атрибутов пользовательского процесса, в чем мы немедленно и убедимся.

Каждый процесс в своем существовании проходит стадии зарождения, исполнения (часто с порождением новых процессов) и завершения (отмирания). Как все это выглядит в реальности, можно рассмотреть на примере самого первого пользовательского процесса, запускающего его командную оболочку по умолчанию (login shell). Для этого опять обратимся к выводу команды ps в форме

% ps l

для того, чтобы видеть идентификаторы родительских процессов (за их показ отвечает опция l). Дополнительно отфильтруем (что это такое, будет объясняться в главе о командных оболочках) процессы, относящиеся только к одной из виртуальных консолей, на которой в данный момент никто не авторизован — для определенности, второй по счету (устройство v1):

% ps l | grep v1

Для пустой, то есть не несущей пользовательского сеанса, консоли вывод последней команды будет примерно таким (я опускаю столбцы, содержание которых в данный момент для нас не существенно):

UID	PID	PPID	COMMAND
0	491	1	/usr/libexec/getty

То есть мы имеем в этой консоли единственный процесс getty, принадлежащий суперпользователю (UID 0), имеющий идентификатор 491 и порожденный процессом init.

После же авторизации вывод той же команды приобретет такой вид:

UID	PID	PPID	COMMAND
0	491	1	login
1001	1949	491	-tcsh

Он свидетельствует, что в нашей экспериментальной консоли запущено уже два процесса — login, показывающий, что на ней зарегистрирован некий пользователь, и командная оболочка последнего — tcsh,

И еще прошу обратить внимание: PID процесса, ассоциированного с командой login, тот же, что и для процесса, исполнявшего перед этим команду getty, Это свидетельствует, что авторизация пользователя не привела к запуску нового процесса — напротив, замещение одной программы другой произошло в рамках одного и того же процесса (одна из причин, почему не следует отождествлять процесс и программу). А вот идентификатор для tcsh — другой: командная оболочка исполняется в порожденном (см. значение PPID) процессе.

Вытеснение одной программы другой в рамках единого процесса — типичный способ запуска новой программы. Так, если из командной строки tcsh мы запустим, например, текстовый редактор joe, то в ответ на

% ps l | grep v1

увидим следующую картину:


UID PID PPID COMMAND 0 491 1 login 1001 1949 491 -tcsh 1001 2208 1949 joe

которая может создать впечатление, будто бы процесс tcsh непосредственно породил процесс joe. Однако это не так. К сожалению, проиллюстрировать динамику зарождения процесса не представляется возможным (по крайней мере, я не знаю, как), поэтому прошу поверить на слово.

На самом деле родительский процесс перво-наперво порождает свою собственную копию — в данном случае еще один экземпляр командной оболочки tcsh (не потому ли первый Shell Борна и получил свое имя, что вызов программы из оболочки напоминает последовательную серию скорлупок?). И различаются в момент зарождения родительский и дочерний процессы фактически только своими PPID (ну и собственными идентификаторами, разумеется). И лишь затем в рамках дочернего процесса осуществляет запуск на исполнение собственно нашей новой программы.

В свою очередь, новый процесс также может выступать в качестве родительского. Так, редактор joe обладает способностью запуска из своей среды программ оболочки. В образовавшемся имитаторе командной строки можно запустить какую-либо другую программу, скажем, поиск файла командой find. Если в процессе поиска посмотреть распределение процессов (например, с другой виртуальной консоли), можно будет увидеть, что процесс joe породил как бы свою копию — но уже с иными идентификаторами (при этом PPID копии, как и следовало ожидать, равен PID оригинала).

Как станет ясным из дальнейшего, понимание механизма создания процессов и запуска программ очень важно. В одной из следующих глав речь пойдет о командных оболочках и вызываемых из них командах. Так вот, большинство команд запускается именно таким образом, как описано выше. Что влечет за собой то, что запущенная программа наследует свойства (т.н. программное окружение) не той командной оболочки, которая выступает в качестве пользовательской, а от ее копии, которую команда заместила в рамках нового процесса. И вполне возможно, что программное окружение материнского и дочернего шеллов окажется разным, что не может не сказаться на выполнении команды. И это — одна из причин, почему пользователю не вредно иметь представление о процессах.

Управление процессами

Второй повод для знакомства с понятием процесса — то, что необходимость управления оными иногда возникает у пользователя. И хотя, к счастью, такое случается всё реже и реже, но уж если эта проблема возникла, то её придётся решать.

Управлять процессами можно двояко. Первый способ — это отдача прямой команды. Например, выход из редактора joe автоматически приводит к отмиранию соответствующего ему процесса, комбинация клавиш Control+Z в большинстве случаев переводит процесс в режим фонового выполнения, и так далее.

Очевидно, что прямое управление возможно только в отношении интерактивных пользовательских процессов, имеющих реально запустившего их хозяина, и управляющий терминал, с которого этот процесс запущен. С процессами-демонами же пользователь может взаимодействовать только посредством посылки им неких сигналов. Сигналы — это также единственный способ ликвидировать безнадежно зависший процесс, который невозможно остановить штатными средствами породившей его программы.

Посылка сигналов осуществляется командой kill. Она требует указания имени сигнала (или соответствующего ему численного значения) и номера процесса, на который нужно оказать воздействие. Так, безнадежно зависший процесс можно попробовать убить следующим образом:

% kill -15 ###

где ### — номер (PID) убиваемого процесса, а 15 — численное значение для сигнала TERM (от terminated). Соответственно, команда эта может быть дана и в форме

% kill -TERM ###

По получении сигнала TERM программа, ассоциированная с процессом ###, пытается по возможности корректно завершить свою работу с записью несохраненных данных.

Однако это ей не всегда удается — в этом случае процесс, соответствующий зависшей программе, продолжает существовать. И тут приходится прибегать к более жесткой форме:


% kill -9 ###

или

% kill -KILL ###

Сигнал KILL не может быть проигнорирован никаким процессом — его получение знаменуется немедленным и неизбежным завершением работы зависшей программы. Разумеется, ни о каком сохранении данных при этом речи идти не может, поэтому применение этого сигнала — крайняя мера.

Есть и еще один способ управления процессами — изменение их приоритета с целью перераспределения ресурсов машины. Однако на практике пользователю с этим почти не приходится сталкиваться, и потому эту тему я затрону лишь вкратце.

Все пользовательские процессы (и большинство системных) по умолчанию запускаются с равным, как бы промежуточным, относительным приоритетом 0. И, соответственно, при многих запущенных задачах ресурсы компьютера (процессорное время и объем оперативной памяти) распределяются между ними (более или менее) равномерно.

При необходимости перераспределения ресурсов между программами можно изменить приоритет выполнения какой-либо из них. При этом пользователь в состоянии только уменьшить приоритет одного или нескольких процессов, хозяином которых он является, администратор же имеет возможность и повысить приоритет любого процесса.

Делается это двояко. Если требуется запустить программу с приоритетом, отличным от обычного, используется команда nice с величиной изменения nice value в качестве опции (предваряемой дефисом) и именем программы в качестве опции. Так, команда

% nice -5 joe

запустит редактор joe с приоритетом, уменьшенным на пять единиц. Если же опустить опцию, приоритет уменьшится на десять единиц. Для увеличения приоритета администратор (и только он) может дать команду

% nice --7 joe

что приведет к росту приоритета (то есть уменьшению "дружелюбия") на семь единиц.

Кроме того, приоритет может быть изменен для уже запущенных процессов с помощью команды renice, параметром которой является новое значение приоритета, а аргументом идентификатор (PID) процесса. Например, команда

% renice 7 735

данная от лица пользователя — владельца процесса с PID 735, приведет к установке для него nice value, равного 7 (при условии, что прежний приоритет этого процесса был выше, например, 3 или 0). Администратор же может понизить приоритет того же процесса до значения nice value, равного 2, с помощью команды

# renice 2 735

или присвоить ему максимальный приоритет:

# renice -20 735

В завершение разговора о процессах повторю, что пользователь может управлять только теми процессами, хозяином которых он является — то есть собственноручно запущенными интерактивными. Администратор системы же располагает правами на управление всеми запущенными процессами, в том числе и неинтерактивными демонами.




Страницы: предыдущая :: 1 :: 2 :: 3

Комментарии

аноним, Fri Jan 23 21:56:54 2009:
я вот прочитал..было интересно появилось желание просмотреть следующую...хотя я и не претендую на знающего систем unix/linux...
Raven, Mon Dec 22 21:54:39 2008:
Рекурсия же встречается в жизни на каждом шагу. Я понимаю, что для влюбленных в BSD она может казаться чем-то волшебным, но в целом обыденное явление, тем более, для любого, знакомого с прораммированием хотя бы поверхностно. Ну а для русских понятие вообще родное - матрешки :)
Raven, Mon Dec 22 21:51:02 2008:
А как насчет того факта, который стеснительно замалчивается поклонниками BSD и Linux-NT семейство является POSIX-совместимыми ОС, с полным наличием всех трех сущностей...
Имхо, крайне натянуто различие. между ними. Современные ОС вообще крайне похожи между собой. Особенно, если вспомнить что такое по сути своей MacOS X и из чего сделана NT.
Разницы между ними особой вообще нет (ну разве что косметическая).
V, Fri Nov 21 08:48:08 2008:
2 Buy
Вот я не даром дважды в посте топологию упомянул. При сколь угодно больших деформациях в реализации, суть остается - пользователи, процессы и файлы никуда не делись и связь между ними осталась той же.

PS
А я и без гугля знаю, как оно реализовано и в чем разница...
Buy, Fri Nov 21 02:20:38 2008:
> вот я прочитал и не понял в чем сие топологическое отличие заключается?

Отличие заключаеться не в наличии у одного и отсутсвии в другом, а в реализации(!), взаимосвязи и взаимодействии. Но это уже материал не для популярной статьи и автор справедливо опустил изложение этих подробностей.
Хочешь докопаться - в Гугле много статей на эту тему :)
V, Fri Nov 21 00:57:52 2008:
"Ибо ими определяется резкое топологическое отличие модели их мироустройства от ... Windows"

вот я прочитал и не понял в чем сие топологическое отличие заключается? ну и в винде тоже есть процессы, пользователи и файлы. и связь между ними точно такая же...
аноним, Thu Nov 20 03:51:31 2008:
lynx

Спасио за статьи. Интересно читать. :)
аноним, Wed Nov 19 11:36:30 2008:
[OT]
>Да и в реальной жизни человек с понятием рекурсии >практически не сталкивается...
Автор либо альтруист, либо не снимает розовых очков...

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds