Вы находитесь на странице: 1из 15

Программирование под OS UNIX

Романенко В.А

Лекция №3 (процессы)
В этой лекции рассматриваются:
• Идентификаторы процесса
• Программный интерфейс управления памятью: системные вызовы низкого уровня и
библиотечные функции, позволяющие упростить управление динамической памятью
процесса.
• Важнейшие системные вызовы, обеспечивающие создание нового процесса и запуск
новой программы. Именно с помощью этих вызовов создается существующая
популяция процессов в операционной системе и ее функциональность.
• Сигналы и способы управления ими. Сигналы можно рассматривать как элементарную
форму межпроцессного взаимодействия, позволяющую процессам сообщать друг
другу о наступлении некоторых событий.
• Группы и сеансы; взаимодействие процесса с пользователем.
• Ограничения, накладываемые на процесс, и функции, которые позволяют управлять
этими ограничениями.

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

Однако нельзя не отметить еще четыре идентификатора, играющие решающую роль


при доступе к системным ресурсам:
- идентификатор пользователя UID,
- эффективный идентификатор пользователя EUID,
- идентификатор группы GID,
- эффективный идентификатор группы EGID.

При регистрации пользователя в системе утилита login(l) запускает командный


интерпретатор, — login shell, имя которого является одним из атрибутов пользователя. При
этом идентификаторам UID (EUID) и GID (EGID) процесса shell присваиваются значения,
полученные из записи пользователя в файле паролей /etc/passwd. Таким образом,
командный интерпретатор обладает правами, определенными для данного пользователя.
При запуске программы командный интерпретатор порождает процесс, который наследует
все четыре идентификатора и, следовательно, имеет те же права, что и shell. Поскольку в
конкретном сеансе работы пользователя в системе прародителем всех процессов является
login shell, то и их пользовательские идентификаторы будут идентичны.
Казалось бы, эту стройную систему могут "испортить" утилиты с установленными
флагами SUID и SGID. Но не стоит волноваться — как правило, такие программы не
позволяют порождать другие процессы, в противном случае, эти утилиты необходимо
немедленно уничтожить!
На рис. 1 показан процесс наследования пользовательских идентификаторов в рамках
одного сеанса работы.

1
Программирование под OS UNIX
Романенко В.А

Рис. 1 Наследование пользовательских идентификаторов

Для получения значений идентификаторов процесса используются следующие


системные вызовы:
#include <sys/types.h>
#include <unistd.h>
uid_t getuid(void);
uid_t geteuid(void);
gid_t getgid(void);
gid_t getegid(void);

Эти функции возвращают для сделавшего вызов процесса соответственно реальный и


эффективный идентификаторы пользователя и реальный и эффективный идентификаторы
группы.
Процесс также может изменить значения этих идентификаторов с помощью системных
вызовов:
#include <sys/types.h>
#include <unistd.h>
int setuid(uid_t uid);
int setegid(gid_t egid);
int seteuid(uid_t euid);
int setgid(gid_t gid) ;

Системные вызовы setuid(2) и setgid(2) устанавливают сразу реальный и эффективный


идентификаторы, а системные вызовы seteuid(2) и setegid(2) — только эффективные.

2
Программирование под OS UNIX
Романенко В.А

Ниже приведен фрагмент программы login(l), изменяющей идентификаторы процесса


на значения, полученные из записи файла паролей. В стандартной библиотеке имеется ряд
функций работы с записями файла паролей, каждая из которых описывается структурой
passwd, определенной в файле <pwd.h>.

Таблица 1 (структура passwd)


Поле ____ Значение _____ _________________
char *pw_name Имя пользователя
char *pw_passwd Строка, содержащая пароль в зашифрованном виде; из соображения
безопасности в большинстве систем пароль хранится в файле
/etc/shadow, а это поле не используется
uid_t pw_uid Идентификатор пользователя
gid_t pw_gid Идентификатор группы
char *pw_gecos Комментарий (поле GECOS), обычно реальное имя пользователя и
дополнительная информация
char *pw_dir Домашний каталог пользователя
char *pw_shell Командный интерпретатор

Функция, которая потребуется для нашего примера, позволяет получить запись файла
паролей по имени пользователя. Она имеет следующий вид:
#include <pwd.h>
struct passwd *getpwnam(const char *name);

Итак, перейдем к фрагменту программы:

struct passwd *pw;


char logname[MAXNAME] ;

/*Массив аргументов при запуске командного интерпретатора*/


char *arg[MAXARG];

/*0кружение командного интерпретатора*/


char *envir[MAXENV];

/*Проведем поиск записи пользователя с именем logname, которое было введено на


приглашение "login:"*/
pw = getpwnam(logname);

/*Если пользователь с таким именем не найден, повторить приглашение*/


if ( pw == 0 ) retry();

/*В противном случае установим идентификаторы процесса равными значениям,


полученным из файла паролей и запустим командный интерпретатор*/
else {
setuid(pw->pw_uid);
setgid(pw->pw_gid);
execve(pw->pw_shell, arg, envir);
}

3
Программирование под OS UNIX
Романенко В.А

Выделение памяти
При обсуждении формата исполняемых файлов и образа программы в памяти мы
отметили, что сегменты данных и стека могут изменять свои размеры. Если для стека
операцию выделения памяти операционная система производит автоматически, то
приложение имеет возможность управлять ростом сегмента данных, выделяя
дополнительную память из хипа (heap — куча) Рассмотрим этот программный интерфейс.
Память, которая используется сегментами данных и стека, может быть выделена
несколькими различными способами как во время создания процесса, так и динамически
во время его выполнения. Существует четыре способа выделения памяти:

1. Переменная объявлена как глобальная, и ей присвоено начальное значение в


исходном тексте программы, например:
char ptype = "Unknown file type";
Строка ptype размещается в сегменте инициализированных данных исполняемого
файла, и для нее выделяется соответствующая память при создании процесса.

2. Значение глобальной переменной неизвестно на этапе компиляции, например:


char ptype[32];
В этом случае место в исполняемом файле для ptype не резервируется, но при создании
процесса для данной переменной выделяется необходимое количество памяти,
заполненной нулями, в сегменте BSS.

3. Переменные автоматического класса хранения, используемые в функциях


программы, используют стек. Память для них выделяется при вызове функции и
освобождается при возврате. Например:
funс1 () {
int a;
char *b;
static int с = 4;
}
В данном примере переменные а и b размещаются в сегменте стека. Переменная с
размещается в сегменте инициализированных данных и загружается из исполняемого
файла либо во время создания процесса, либо в процессе загрузки страниц по требованию.

4. Выделение памяти явно запрашивается некоторыми системными вызовами или


библиотечными функциями. Например, библиотечная функция malloc(3C) запрашивает
выделение дополнительной памяти, которая в дальнейшем используется для
динамического размещения данных. Функция ctime(3C), предоставляющая системное
время в удобном формате, также требует выделения памяти для размещения строки,
содержащей значения текущего времени, указатель на которую возвращается программе.

Напомним, что дополнительная память выделяется из хипа (heap) — области


виртуальной памяти, расположенной рядом с сегментом данных, Размер которой меняется
для удовлетворения запросов на размещение. Следующий за сегментом данных адрес
называется разделительным или брейк-адресом (break address). Изменение размера
сегмента данных по существу заключается в изменении брейк-адреса. Для изменения его
значения UNIX предоставляет процессу два системных вызова — brk(2) и sbrk(2).
#include <unistd.h>
int brk(void *endds);
void *sbrk(int incr) ;

4
Программирование под OS UNIX
Романенко В.А

Системный вызов brk(2) позволяет установить значение брейк-адреса равным endds и, в


зависимости от его значения, выделяет или освобождает память (рис. 2). Функция sbrk(2)
изменяет значение брейк-адреса на величину incr. Если значение incr больше 0,
происходит выделение памяти, в противном случае, память освобождается.

Рис.2 Динамическое выделение памяти с помощью brk(2)

Заметим, что в некоторых системах дополнительная память выделяется (или


освобождается) в порциях, кратных размеру страницы. Например, выделение всего 100
байтов на caмом деле приведет к выделению 4096 байтов, если размер страницы равен 4К.

Существуют четыре стандартные библиотечные функции, предназначенные для


динамического выделения/освобождения памяти.
#nclude <stdlib.h>
void *malloc(size_t size);
void *calloc(size_t nelem, size_t elsize);
void *realloc(void *ptr, size_t size);
void free(void *ptr);

Функция malloc(3C) выделяет указанное аргументом size число байтов.


Функция саllос(ЗС) вьделяет память для указанного аргументом nelem числа объектов,
размер которых elsize. Выделенная память инициализируется нулями.
Функция realloc(3C) изменяет размер предварительно выделенной области памяти
(увеличивает или уменьшает, в зависимости от знака аргумента size). Увеличение размера
может привести к перемещению всей области в другое место виртуальной памяти, где
имеется необходимое свободное непрерывное виртуальное адресное пространство.
Функция free(3C) освобождает память, предварительно выделенную с помощью
функций malloc(3C), саllс(ЗС) или realloc(3C), указатель на которую передается через
аргумент ptr.

Упомянутые библиотечные функции обычно используют системные вызовы sbrk(2) или


brk(2). Хотя эти системные вызовы позволяют как выделять, так и освобождать память, в
случае библиотечных функций память реально не освобождается, даже при вызове
free(3C). Правда, с помощью функций malloc(3C), саllос(ЗС) или realloc(3C) можно снова
выделить и использовать эту память и снова освободить ее, но она не передается обратно
ядру, а остается в пуле malloc(3C).
Для иллюстрации этого положения приведем небольшую программу, выделяющую и
освобождающую память с помощью функций malloc(3C) и free(3C), соответственно.
Контроль действительного значения брейк-адреса осуществляется с помощью системного
вызова sbrk(2)
#include <unistd.h>

5
Программирование под OS UNIX
Романенко В.А

#include <stdlib.h>
main () {
char *obrk;
char *nbrk;
char *naddr; /*0пределим текущий брейк-адрес*/
obrk = sbrk(O);
printf("Текущий брейк-адрес= Ox%x\n", obrk); /*Выделим 64 байта из хипа*/
naddr = malloc(64);
printf("malloc(64)\n"); /^Определим новый брейк-адрес*/
nbrk = sbrk(O);
printf("Новый адрес области malloc= Ox%x, брейк-адрес= Ох%х (увеличение на %d
байтов)\п",
naddr, nbrk, nbrk — obrk);
/*"Освободим" выделенную память и проверим, что произошло на самом деле*/
free(naddr);
printf("free(Ox%x)\n", naddr);
obrk = sbrk(O);
printf("Новый брейк-адрес= Ох%х (увеличение на %d байтов)\п", obrk, obrk —
nbrk); }

Откомпилируем и запустим программу:


$a.out
Текущий брейк-адрес= Ох20асО malloc(64)
Новый адрес области malloc = Ох20ас8, брейк-адрес = Ох22асО (увеличение на 8192
байтов) free(Ox20ac8)
Новый брейк-адрес = Ох22асО (увеличение на 0 байтов) $

Создание и управление процессами


В UNIX порождение процесса четко разделено на два этапа. Соответственно система
предоставляет два различных системных вызова: один для создания процесса, а другой
для запуска новой программы.

Новый процесс порождается с помощью системного вызова fork(2):


#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);

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

Более того, виртуальная память дочернего процесса не отличается от образа


родительского: такие же сегменты кода, данных, стека, разделяемой памяти и т. д. После

6
Программирование под OS UNIX
Романенко В.А

возврата из вызова fork(2), который происходит и в родительский и в дочерний процессы,


оба начинают выполнять одну и ту же инструкцию.
Легче перечислить немногочисленные различия между этими процессами, а именно:
- дочернему процессу присваивается уникальный идентификатор PID,
- идентификаторы родительского процесса PPID у этих процессов различны,
- дочерний процесс свободен от сигналов, ожидающих доставки,
- значение, возвращаемое системным вызовом fork(2) различно для родителя и
потомка.

Возврат из функции fork(2) происходит как в родительский, так и в дочерний процесс.


При этом возвращаемое родителю значение равно PID дочернего процесса, а дочерний, в
свою очередь, получает значение, равное 0. Если fork(2) возвращает -1, то это
свидетельствует об ошибке (естественно, в этом случае возврат происходит только в
процесс, выполнивший системный вызов).

В возвращаемом fork(2) значении заложен большой смысл, поскольку оно позволяет


определить, кто является родителем, а кто — потомком, и соответственно разделить
функциональность. Поясним это на примере:

main () {
int pid;
pid = fork ();
if (pid == -1){
perror("fork"); exit(l);}
if (pid == 0) {
/*Эта часть кода выполняется дочерним процессом*/
printf("Потомок\п"); }
else {
. /*Эта часть кода выполняется родительским процессом*/ printf("РодительХп");
}
}

Таким образом, порождение нового процесса уже не кажется абсолютно


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

UNIX предлагает системный вызов, предназначенный исключительно для запуска


программ, т. е. загрузки другого исполняемого файла. Это системный вызов ехес(2),
представленный на программном уровне несколькими модификациями:
#include <unistd.h>
int execl(const char *path, const char *argO, ...,const char *argn, char * /*NULL*/);
int execv(const char *path, char *const argv[]);
int execle (const char *path,char *const argO[], ... ,const char *argn, char * /*NULL*/, char
*const envp[]);
int execve (const char *path, char *const argv[],char *const envp[]);
int execlp (const char *file, const char *argO, ...,const char *argn, char * /*NULL*/);
int execvp (const char *file, char *const argv[]);

Все эти функции по существу являются надстройками системного вызова execve(2),


который в качестве аргументов получает имя запускаемой программы (исполняемого

7
Программирование под OS UNIX
Романенко В.А

файла), набор аргументов и список переменных окружения. После выполнения execve(2)


не создается новый процесс, а образ существующего полностью заменяется на образ,
полученный из указанного исполняемого файла.
В отличие от вызова fork(2), новая программа наследует меньше атрибутов. В
частности, наследуются:
- идентификаторы процесса PID и PPID,
- идентификаторы пользователя и группы,
- эффективные идентификаторы пользователя и группы (в случае, если для
исполняемого файла не установлен флаг SUID или SGID),
- ограничения, накладываемые на процесс,
- текущий и корневой каталоги,
- маска создания файлов,
- управляющий терминал,
- файловые дескрипторы, для которых не установлен флаг FD_CLOEXEC.

Наследование характеристик процесса играет существенную роль в работе


операционной системы. Так наследование идентификаторов владельцев процесса
гарантирует преемственность привилегий и, таким образом, неизменность привилегий
пользователя при работе в UNIX. Наследование файловых дескрипторов позволяет
установить направления ввода/вывода для нового процесса или новой программы. Именно
так действует командный интерпретатор.

Контролирование потомков
Операционная система предоставляет процессу ряд функций, позволяющих ему
контролировать выполнение потомков. Это функции wait(2), waitid(2) и waitpid(2):
#include <sys/types.h>
#include <sys/wait.h>
pid_t wait(int *stat_loc);
int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options);
pid_t waitpid(pid_t pid, int *stat_loc, int options);

Вызов wait(2) - позволяет заблокировать выполнение процесса, пока кто-либо из его


непосредственных потомков не прекратит существование. Вызов wait(2) немедленно
возвратит состояние уже завершившегося дочернего процесса в переменной stat_loc.
Значение stat_loc может быть проанализировано с помощью следующих
макроопределений:

WIFEXITED(status) истинна (ненулевое) значение, если процесс завершился


нормально.
WEXITSTATUS (status) Если WIFEXITED(status) не равно нулю, определяет код
возврата завершившегося процесса (аргумент функции exit(2)).
WIFSIGNALLED (status) Возвращает истину, если процесс завершился по сигналу.
WTERMSIG (status) Если WIFSIGNALLED(status) не равно нулю, определяет
номер сигнала, вызвавшего завершение выполнения процесса.
WCOREDUMP(status) Если WIFSIGNALLED(status) не равно нулю, макрос
возвращает истину в случае создания файла core.

Вызов waitid(2) предоставляет больше возможностей для контроля дочернего процесса.


Аргументы idtype и id определяют, за какими именно из дочерних процессов требуется
следить:

8
Программирование под OS UNIX
Романенко В.А

Значение аргумен idtype Описание


P_PID waitid(2) блокирует выполнение процесса, следя за потомком,
PID которого равен id.
P_PGID waitid(2) блокирует выполнение процесса, следя за потомками,
идентификаторы группы которых равны id.
P_ALL waitid(2) блокирует выполнение процесса, следя за всеми
непосредственными потомками.

Аргумент options содержит флаги, объединенные логическим ИЛИ, определяющие, за


какими изменениями в состоянии потомков следит waitid(2):

Флаги аргумента options Описание


WEXITED Предписывает ожидать завершения выполнения процесса.
WTRAPPED Предписывает ожидать ловушки (trap) или точки останова
(breakpoint) для трассируемых процессов.
WSTOPPED Предписывает ожидать останова процесса из-за получения сигнала.
WCONTINUED Предписывает вернуть статус процесса, выполнение которого было
продолжено после останова.
WNOHANG Предписывает завершить свое выполнение, если отсутствует
статусная информация (т. е. отсутствует ожидаемое событие).
WNOWAIT Предписывает получить статусную информацию, но не
уничтожать ее, оставив дочерний процесс в состоянии ожидания.

Аргумент infop указывает на структуру siginfo_t, которая будет заполнена информацией


о потомке.

Функция waitpid(2), как и функции wait(2) и waitid(2), позволяет контролировать


определенное множество дочерних процессов.

В заключение для иллюстрации описанных в этом разделе системных вызовов


приведем схему работы командного интерпретатора при запуске команды.

/*Вывести приглашение shell*/


write (1, "$ ", 2);
/*Считать пользовательский ввод*/
get_input(inputbuf);
/*Произвести разбор ввода: выделить команду cmd и ее аргументы arg[]*/
parse_input(inputbuf, cmd, arg);
/*Породить процесс*/
pid = fork();
if (pid ==0}
{
/*3апустить программу*/
execvp(cmd, arg);
/*При нормальном запуске программы эта часть кода выполняться уже не будет — можно
смело выводить сообщение об ошибке*/
pexit (cmd) ;
}
else
/*Родительский процесс (shell) ожидает завершения выполнения потомка*/
wait(&status);

9
Программирование под OS UNIX
Романенко В.А

Сигналы
Сигнал является способом передачи уведомления о некотором произошедшем событии
между процессами или между ядром системы и процессами. Сигналы можно
рассматривать, как простейшую форму межпроцессного взаимодействия.
Сигнал имеет уникальное символьное имя и соответствующий ему номер.
Сигнал может быть отправлен процессу либо ядром, либо другим процессом с
помощью системного вызова kill(2):
#include <sys/types.h>
#include <signal.h>
int kill(pid_t pid, int sig);

Аргумент pid адресует процесс, которому посылается сигнал.


Аргумент sig определяет тип отправляемого сигнала.

Ситуации которые могут привести к генерации сигнала:


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

С помощью системного вызова kill(2) процесс может послать сигнал как самому себе,
так и другому процессу или группе процессов.
Процесс, посылающий сигнал, должен иметь те же реальный и эффективный
идентификаторы, что и процесс, которому сигнал отправляется.
Данное ограничение не распространяется на процессы, обладающие привилегиями
суперпользователя.

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

Сигналы SIGKILL и SIGSTOP невозможно ни игнорировать, ни перехватить. Сигнал


SIGKILL является силовым методом завершения выполнения "непослушного" процесса, а от
работоспособности SIGSTOP зависит функционирование системы управления заданиями.

При получении сигнала в большинстве случаев по умолчанию происходит завершение


выполнения процесса. В ряде случаев в текущем рабочем каталоге процесса создается
файл core, в котором хранится образ памяти процесса. Этот файл может быть
впоследствии проанализирован программой-отладчиком для определения состояния
процесса непосредственно перед завершением.

Файл core не будет создан в следующих случаях:


- исполняемый файл процесса имеет установленный бит SUID, и реальный владелец-
пользователь процесса не является владельцем-пользователем исполняемого файла;
- исполняемый файл процесса имеет установленный бит SGID, и реальный владелец-
группа процесса не является владельцем-группой исполняемого файла;
- процесс не имеет права записи в текущем рабочем каталоге;
- размер файла core слишком велик.

10
Программирование под OS UNIX
Романенко В.А

Группы и сеансы
После создания процесса ему присваивается уникальный идентификатор,
возвращаемый системным вызовом fork(2) родительскому процессу. Дополнительно ядро
назначает процессу идентификатор группы процессов (process group ID).
Группа процессов включает один или более процессов и существует, пока в системе
присутствует хотя бы один процесс этой группы. Временной интервал, начинающийся с
создания группы и заканчивающийся, когда последний процесс ее покинет, называется
временем жизни группы. Последний процесс может либо завершить свое выполнение,
либо перейти в другую группу.
Многие системные вызовы могут быть применены как к единичному процессу, так и ко
всем процессам группы.
Каждый процесс является членом сеанса (session), являющегося набором одной или
нескольких групп процессов.
Процесс имеет возможность определить идентификатор собственной группы процессов
или группы процесса, который является членом того же сеанса. Для этого используются
два системных вызова: getpgrp(2) и getpgid(2):
#include <sys/types.h>
#include <unistd.h>
pid_t getpgrp(void);
pid_t getpgid(pid_t pid);

Аргумент pid, который передается функции getpgid(2), адресует процесс,


идентификатор группы которого требуется узнать. Если этот процесс не принадлежит к
тому же сеансу, что и процесс, сделавший системный вызов, функция возвращает ошибку.
Системный вызов setpgid(2) позволяет процессу стать членом существующей группы
или создать новую группу.
#include <sys/types.h>
#include <unistd.h>
int setpgid(pid_t pid, pid_t pgid);

Функция устанавливает идентификатор группы процесса pid равным pgid.


Процесс имеет возможность установить идентификатор группы для себя и для своих
потомков (дочерних процессов). Однако процесс не может изменить идентификатор
группы для дочернего процесса, который выполнил системный вызов ехес(2),
запускающий на выполнение другую программу.
Если значения обоих аргументов равны, то создается новая группа с идентификатором
pgid, а процесс становится лидером (group leader) этой группы. Поскольку именно таким
образом создаются новые группы, их идентификаторы гарантированно уникальны.
Идентификатор сеанса можно узнать с помощью функции getsid(2):
#include <sys/types.h>
#include <unistd.h>
pid_t getsid(pid_t pid);

Вызов функции setsid(2) приводит к созданию нового сеанса:


#include <sys/types.h>
#include <unistd.h>
pid_t setsid(void) ;

11
Программирование под OS UNIX
Романенко В.А

Новый сеанс создается лишь при условии, что процесс не является лидером какого-
либо сеанса. В случае успеха процесс становится лидером сеанса и лидером новой
группы.
Для каждого управляющего терминала существует сеанс, включающий одну или
несколько групп процессов. Одна из этих групп является текущей (foregroud group), а
остальные фоновыми (background group).
Ограничения
UNIX является многозадачной системой. Это значит, что несколько процессов
конкурируют между собой при доступе к различным ресурсам. Для "справедливого"
распределения разделяемых ресурсов, таких как память, дисковое пространство и т. п.,
каждому процессу установлен набор ограничений. Эти ограничения не носят
общесистемного характера, как, например, максимальное число процессов или областей, а
устанавливаются для каждого процесса отдельно. Для получения информации о текущих
ограничениях и их изменения предназначены системные вызовы getrlimit(2) и setrlimit(2):
#include <sys/time.h>
#nclude <sys/resource.h>
int getrlimit(int resource, struct rlimit *rlp);
int setrlimit(int resource, const struct rlimit *rlp);

Аргумент resource определяет вид ресурса, для которого мы хотим узнать или изменить
ограничения процесса.
Структура rlimit состоит из двух полей:
rlim_t rlim_cur;
rlim_t rlim_max;

определяющих, соответственно, изменяемое (soft) и жесткое (hard) ограничение.


Первое определяет текущее ограничение процесса на данный ресурс, а второе —
максимальный возможный предел потребления ресурса. Например, изменяемое
ограничение на число открытых процессом файлов может составлять 64, в то время как
жесткое ограничение равно 1024.
Процессы - Демоны
Демоны играют важную роль в работе операционной системы. Достаточно будет
сказать, что возможность терминального входа пользователей в систему, доступ по сети,
использование системы печати и электронной почты, — все это обеспечивается
соответствующими демонами — неинтерактивными программами, составляющими
собственные сеансы (и группы) и не принадлежащими ни одному из пользовательских
сеансов (групп).
Некоторые демоны работают постоянно, наиболее яркий пример такого демона —
процесс init(lM), являющийся прародителем всех прикладных процессов в системе.
Другими примерами являются сгоп(Ш), позволяющий запускать профаммы в
определенные моменты времени, inetd(lM), обеспечивающий доступ к сервисам системы
из сети, и sendmail(lM), обеспечивающий получение и отправку электронной почты.
В отношении демонов можно сформулировать ряд правил, определяющих их
нормальное функционирование, которые необходимо учитывать при разработке таких
профамм:
1. Демон не должен реагировать на сигналы управления заданиями, посылаемые ему
при попытке операций ввода/вывода с управляющим терминалом. Начиная с некоторого

12
Программирование под OS UNIX
Романенко В.А

времени, демон снимает ассоциацию с управляющим терминалом, но на начальном этапе


запуска ему может потребоваться вывести то или иное сообщение на экран.
2. Необходимо закрыть все открытые файлы (файловые дескрипторы), особенно
стандартные потоки ввода/вывода. Многие из этих файлов представляют собой
терминальные устройства, которые должны быть закрыты, например, при выходе
пользователя из системы. Предполагается, что демон остается работать и после того, как
пользователь "покинул" UNIX.
3. Необходимо снять его ассоциацию с группой процессов и управляющим
терминалом. Это позволит демону избавиться от сигналов, генерируемых терминалом
(SIGINT или SIGHUP), например, при нажатии определенных клавиш или выходе
пользователя из системы.
4. Сообщения о работе демона следует направлять в специальный журнал с помощью
функции syslog(3), — это наиболее корректный способ передачи сообщений от демона.
5. Необходимо изменить текущий каталог на корневой. Если этого не сделать, а
текущий каталог, допустим, находится на примонтирован-ной файловой системе,
последнюю нельзя будет размонтировать. Самым надежным выбором является корневой
каталог, всегда принадлежащий корневой файловой системе.
Процессы – Зомби
Если дочерний процесс завершается в то время, когда родительский процесс заблоки-
рован функцией wait (), он успешно удаляется и его код завершения передается предку
через функцию wait (). Но что произойдет, если потомок завершился, а родительский
процесс так и не вызвал функцию wait() ? Дочерний процесс просто исчезнет? Нет, ведь в
этом случае информация о его завершении (было ли оно аварийным или нет и каков код
завершения) пропадет. Вместо этого дочерний процесс становится процессом-зомби.
Зомби— это процесс, который завершился, но не был удален. Удаление зомби возлагается
на родительский процесс. Функция wait () тоже это делает, поэтому перед ее вызовом не
нужно проверять, продолжает ли выполняться требуемый дочерний процесс.
Предположим, к примеру, что программа создает дочерний процесс, выполняет нужные
вычисления и затем вызывает функцию wait (). Если к тому времени дочерний процесс
еще не завершился, функция wait () заблокирует программу. В противном случае процесс
на некоторое время превратится в зомби. Тогда функция wait () извлечет код его завер-
шения, система удалит процесс и функция немедленно завершится.
Что же все-таки случится, если родительский процесс не удалит своих потомков?
Они останутся в системе в виде зомби. Программа порождает дочерний процесс, который
немедленно завершается, тогда как родительский процесс берет минутную паузу, после
чего тоже заканчивает работу, так и не позаботившись об удалении потомка.
Листинг (zombie.c) Создание процесса-зомби
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main ()
{ pid_t child_pid;

/* Создание дочернего процесса. */


child_pid = fork ();
if (child_pid > 0) {
/* Это родительский процесс -- делаем минутную паузу. */
Sleep (60);
} else {

13
Программирование под OS UNIX
Романенко В.А

/* Это дочерний процесс -- немедленно завершаем работу. */


exit (0);
}
return 0;
}

Скомпилируйте этот файл и запустите программу. Пока программа работает, перейдите


в другое окно и просмотрите список процессов с помощью следующей команды:
% ps -е -о pid, ppid, stat, cmd
Эта команда отображает идентификатор самого процесса и его предка, а также статус
процесса и его командную строку. Обратите внимание на присутствие двух процессов с
именем zombie. Один из них— предок, другой— потомок. У последнего идентификатор
родительского процесса равен идентификатору основного процесса zombie, при этом по-
томок обозначен как <defunct> (несуществующий), а его код состояния равен Z (т.е. zombie
— зомби).
Итак, мы хотим узнать, что будет, когда программа zombie завершится, не вызвав
функцию wait (). Останется ли процесс-зомби? Нет — выполните команду ps и убедитесь в
этом: оба процесса zombie исчезли. Дело в том, что после завершения программы
управление ее дочерними процессами принимает на себя специальный процесс — демон
init, который всегда работает, имея идентификатор 1 (это первый процесс, запускаемый
при загрузке Linux). Демон init автоматически удаляет все унаследованные им дочерние
процессы-зомби.

Асинхронное удаление дочерних процессов


Если дочерний процесс просто вызывает другую программу с помощью функции
exec (), то в родительском процессе можно сразу же вызвать функцию wait () и пассивно
дожидаться завершения потомка. Но очень часто нужно, чтобы родительский процесс
продолжал выполняться одновременно с одним или несколькими своими потомками. Как в
этом случае получать сигналы об их завершении?
Один подход заключается в периодическом вызове функции wait3() или wait4 ().
Функция wait {) в данной ситуации не подходит, так как в случае отсутствия завершивше-
гося дочернего процесса она заблокирует основную программу. А вот упомянутые две
функции принимают дополнительный флаг WNOHANG, переводящий их в
неблокируемый режим, в котором функция либо удаляет дочерний процесс, если он есть,
либо просто завершается. В первом случае возвращается идентификатор процесса, во
втором — 0.
Более элегантный подход состоит в асинхронном уведомлении родительского процесса о
завершении потомка. Существуют разные способы сделать это, но проще всего вос-
пользоваться сигналом SIGCHLD, посылаемым как раз тогда, когда завершается дочерний
процесс. По умолчанию программа никак не реагирует на этот сигнал, поэтому раньше вы
могли и не знать о его существовании.
Таким образом, нужно организовать удаление дочерних процессов в обработчике сиг-
нала SIGCHLD. Естественно, код состояния удаляемого процесса следует сохранять в гло-
бальной переменной, если эта информация необходима основной программе. В листинге
показана программа, в которой реализована данная методика.

Листинг (sigchld.c) Удаление дочерних процессов в обработчике сигнала SIGCHLD


#include <signal.h>
#include <string.h>
#include <sys/types.h>

14
Программирование под OS UNIX
Романенко В.А

#include <sys/wait.h>

sig_atomic_t child_exit_status;

void clean_up_child_process (int signal_number)


{
/* Удаление дочернего процесса. */
int status;
wait (&status);

/* Сохраняем статус потомка в глобальной переменной. */


child_exit_status = status;
}

int main ()
{
/* Обрабатываем сигнал SIGCHLD, функция clean_up_child_process(). */
struct sigaction sigchld_action;
memset (&sigchld_action, 0, sizeof (sigchld_action));
sigchld_action.sa_handler = &clean_up_child_process;
sigaction (SIGCHLD, &sigchld_action, NULL);

/* Далее выполняются основные действия, включая порождение


дочернего процесса. */
/*... */
return 0;
}

15