Процессы и сигналы формируют главную часть операционной среды Linux. Они управляют почти всеми видами деятельности ОС Linux и UNIX-подобных компьютерных систем. Понимание того, как Linux и UNIX управляют процессами, сослужит добрую службу системным и прикладным программистам или системным администраторам.

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

□ структуре процесса, его типе и планировании;

□ разных способах запуска новых процессов;

□ порождающих (родительских), порожденных (дочерних) процессах и процессах-зомби;

□ сигналах и их применении.

Стандарты UNIX, а именно IEEE Std 1003.1, 2004 Edition, определяют процесс как "адресное пространство с одним или несколькими потоками, выполняющимися в нем, и системные ресурсы, необходимые этим потокам. Мы будем рассматривать потоки в главе 12, а пока будем считать процессом просто любую выполняющуюся программу.

Многозадачные системы, такие как Linux, позволяют многим программам выполняться одновременно. Каждый экземпляр выполняющейся программы создает процесс. Это особенно заметно в оконной системе, например Window System (часто называемой просто X). Как и ОС Windows, X предоставляет графический пользовательский интерфейс, позволяющий многим приложениям выполняться одновременно. Каждое приложение может отображаться в одном или нескольких окнах.

Будучи многопользовательской системой, Linux разрешает многим пользователям одновременно обращаться к системе. Каждый пользователь в одно и то же время может запускать много программ или даже несколько экземпляров одной и той же программы. Сама система выполняет в это время другие программы, управляющие системными ресурсами и контролирующие доступ пользователей.

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

Давайте посмотрим, как организовано сосуществование двух процессов в операционной системе. Если два пользователя neil и rick запускают в одно и то же время программу grep для поиска разных строк в различных файлах, применяемые для этого процессы могут выглядеть так, как показано на рис. 11.1.

Рис. 11.1 

Если вы сможете выполнить команду

ps

$ ps -ef

UID  PID PPID С STIME TTY  TIME     CMD

rick 101 96   0 18:24 tty2 00:00:00 grep troi nextgen.doc

neil 102 92   0 18:24 tty4 00:00:00 grep kirk trek.txt

Каждому процессу выделяется уникальный номер, именуемый идентификатором процесса или PID. Обычно это положительное целое в диапазоне от 2 до 32 768. Когда процесс стартует, в последовательности выбирается следующее неиспользованное число. Когда все номера будут исчерпаны, выбор опять начнется с 2. Номер 1 обычно зарезервирован для специального процесса

init

init

Код программы, которая будет выполняться командой

grep

Системные библиотеки также можно совместно использовать. Следовательно, в памяти нужна, например, только одна копия функции

printf

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

grep

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

grep

s

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

putenv

getenv

Во многих системах Linux и некоторых системах UNIX существует специальный набор "файлов" в каталоге /proc. Это скорее специальные, чем истинные файлы, т.к. позволяют "заглянуть внутрь" процессов во время их выполнения, как если бы они были файлами в каталогах, В главе 3 мы приводили краткий обзор файловой системы /proc.

И наконец, поскольку Linux, как и UNIX, обладает системой виртуальной памяти, которая удаляет страницы кода и данных на жесткий диск, можно управлять гораздо большим количеством процессов, чем позволяет объем физической памяти.

Таблица процессов Linux подобна структуре данных, описывающей все процессы, загруженные в текущий момент, например, их PID, состояние и строку команды, разновидность информационного вывода команды

ps

Команда

ps

$ ps -ef

UID  PID PPID  С STIME  TTY      TIME CMD

root 433  425  0 18:12  tty1 00:00:00 [bash]

rick 445  426  0 18:12  tty2 00:00:00 -bash

rick 456  427  0 18:12  tty3 00:00:00 [bash]

root 467  433  0 18:12  tty1 00:00:00 sh /usr/X11R6/bin/startx

root 474  467  0 18:12  tty1 00:00:00 xinit /etc/X11/xinit/xinitrc --

root 478  474  0 18:12  tty1 00:00:00 /usr/bin/gnome-session

root 487    1  0 18:12  tty1 00:00:00 gnome-smproxy --sm-client-id def

root 493    1  0 18:12  tty1 00:00:01 [enlightenment]

root 506    1  0 18:12  tty1 00:00:03 panel --sm-client-id defaults

root 508    1  0 18:12  tty1 00:00:00 xscreensaver -no-splash -timeout

root 510    1  0 18:12  tty1 00:00:01 gmc --sm-client-id default10

root 512    1  0 18:12  tty1 00:00:01 gnome-help-browser --sm-client-i

root 649  445  0 18:24  tty2 00:00:00 su

root 653  649  0 18:24  tty2 00:00:00 bash

neil 655  428  0 18:24  tty4 00:00:00 -bash

root 713    1  2 18:27  tty1 00:00:00 gnome-terminal

root 715  713  0 18:28  tty1 00:00:00 gnome-pty-helper

root 717  716 13 18:28 pts/0 00:00:01 emacs

root 718  653  0 18:28  tty2 00:00:00 ps -ef

Вывод отображает информацию о многих процессах, включая процессы, запущенные редактором Emacs в графической среде X ОС Linux. Например, столбец

TTY

TIME

CMD

neil 655  428  0 18:24  tty4 00:00:00 -bash

Начальная регистрация была произведена на консоли номер 4. Это просто консоль на данном компьютере. Выполняемая программа командной оболочки — это стандартная оболочка Linux,

bash

root 467  433  0 18:12  tty1 00:00:00 sh /usr/X11R6/bin/startx

X Window System была запущена командой

startx

root 717  716 13 18:28 pts/0 00:00:01 emacs

Этот процесс представляет окно в системе X, выполняющее программу Emacs. Он был запущен оконным диспетчером в ответ на запрос нового окна. Командной оболочке был назначен новый псевдотерминал pts/0 для считывания и записи.

root 512    1  0 18:12  tty1 00:00:01 gnome-help-browser --sm-client-i

Это обозреватель системы помощи среды GNOME, запущенный оконным диспетчером.

По умолчанию программа

ps

ps

-е

-f

Примечание

Точная синтаксическая запись команды

ps

и формат вывода могут немного отличаться в разных системах. Версия GNU команды

ps

, применяемая в Linux, поддерживает опции, взятые из нескольких предшествующих реализаций

ps

, включая варианты из UNIX-систем BSD и AT&T, и добавляет множество своих опций. См. интерактивное справочное руководство для получения подробных сведений о доступных опциях и форматах вывода команды

ps

.

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

ps

STAT

Таблица 11.1

$ ps ах

PID   TTY   STAT TIME COMMAND

1     ?     Ss   0:03 init [5]

2     ?     S    0:00 [migration/0]

3     ?     SN   0:00 [ksoftirqd/0]

4     ?     S<   0:05 [events/0]

5     ?     S<   0:00 [khelper]

6     ?     S<   0:00 [kthread]

840   ?     S<   2:52 [kjournald]

888   ?     S<s  0:03 /sbin/udevd --daemon

3069  ?     Ss   0:00 /sbin/acpid

3098  ?     Ss   0:11 /usr/sbin/hald --daemon=yes

3099  ?     S    0:00 hald-runner

8357  ?     Ss   0:03 /sbin/syslog-ng

8677  ?     Ss   0:00 /opt/kde3/bin/kdm

9119  ?     S    0:11 konsole [kdeinit]

9120  pts/2 Ss   0:00 /bin/bash

9151  ?     Ss   0:00 /usr/sbin/cupsd

9457  ?     Ss   0:00 /usr/sbin/cron

9479  ?     Ss   0:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid

9618  tty1  Ss+  0:00 /sbin/mingetty --noclear tty1

9619  tty2  Ss+  0:00 /sbin/mingetty tty2

9621  tty3  Ss+  0:00 /sbin/mingetty tty3

9622  tty4  Ss+  0:00 /sbin/mingetty tty4

9623  tty5  Ss+  0:00 /sbin/mingetty tty5

9638  tty6  Ss+  0:00 /sbin/mingetty tty6

10359 tty1  Ss+ 10:05 /usr/bin/Xorg -br -nolisten tcp :0 vt7 -auth

10360 ?     S    0:00 -:0

10381 ?     Ss   0:00 /bin/sh /usr/bin/kde

10438 ?     Ss   0:00 /usr/bin/ssh-agent /bin/bash /etc/X11/xinit/xinitrc

10478 ?     S    0:00 start_kdeinit --new-startup +kcminit_startup

10479 ?     Ss   0:00 kdeinit Running...

10500 ?     S    0:53 kdesktop [kdeinit]

10502 ?     S    1:54 kicker [kdeinit]

10524 ?     Sl   0:47 beagled /usr/lib/beagle/BeagleDaemon.exe --bg

10530 ?     S    0:02 opensuseupdater

10539 ?     S    0:02 kpowersave [kdeinit]

10541 ?     S    0:03 klipper [kdeinit]

10555 ?     S    0:01 kio_uiserver [kdeinit]

10688 ?     S    0:53 konsole [kdeinit]

10689 pts/1 Ss+  0:07 /bin/bash

10784 ?     S    0:00 /opt/kde3/bin/kdesud

11052 ?     S    0:01 [pdflush]

19996 ?     SN1  0:20 beagled-helper /usr/lib/beagle/IndexHelper.exe

20254 ?     S    0:00 qmgr -1 -t fifo -u

21192 ?     Ss   0:00 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -u ntp -i /v

21198 ?     S    0:00 pickup -1 -t fifo -u

21475 pts/2 R+   0:00 ps ax

Здесь вы видите на самом деле очень важный процесс

1     ?     Ss   0:03 init [5]

В основном каждый процесс запускается другим процессом, называемым родительским или порождающим процессом. Подобным образом запущенный процесс называют дочерним или порожденным. Когда стартует ОС Linux, она выполняет единственную программу, первого предка и процесс с номером 1,

init

init

init

Один из таких примеров — процедура регистрации. Процесс

init

getty

ps

9619  tty2  Ss+  0:00 /sbin/mingetty tty2

Процессы

getty

init

getty

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

fork

exec

wait

В следующем примере вывода команды

ps

ps

21475 pts/2 R+   0:00 ps ax

Эта строка означает, что процесс

21475

R

ps ах

R+

команды

Ядро Linux применяет планировщик процессов для того, чтобы решить, какой процесс получит следующий квант времени. Решение принимается исходя из приоритета процесса (мы обсуждали приоритеты процессов в главе 4). Процессы с высоким приоритетом выполняются чаще, а другие, такие как низкоприоритетные фоновые задачи, — реже. В ОС Linux процессы не могут превысить выделенный им квант времени. Они преимущественно относятся к разным задачам, поэтому приостанавливаются и возобновляются без взаимодействия друг с другом. В более старых системах, например Windows 3.х, как правило, для возобновления других процессов требовалось явное согласие процесса.

В многозадачных системах, таких как Linux, несколько программ могут претендовать на один и тот же ресурс, поэтому программы с короткими рабочими циклами, прерывающиеся для ввода, считаются лучше ведущими себя, чем программы, прибирающие к рукам процессор для продолжительного вычисления какого-либо значения или непрерывных запросов к системе, касающихся готовности ввода данных. Хорошо ведущие себя программы называют nice-программами (привлекательными программами) и в известном смысле эту "привлекательность" можно измерить. Операционная система определяет приоритет процесса на основе значения "nice", по умолчанию равного 0, и поведения программы. Программы, выполняющиеся без пауз в течение долгих периодов, как правило, получают более низкие приоритеты. Программы, делающие паузы время от времени, например в ожидании ввода, получают награду. Это помогает сохранить отзывчивость программы, взаимодействующей с пользователем; пока она ждет какого-либо ввода от пользователя, система увеличивает ее приоритет, чтобы, когда программа будет готова возобновить выполнение, у нее был высокий приоритет. Задать значение

nice

nice

renice

nice

nice

nice

-l

-f

ps

NI

$ ps -l

  F S UID  PID PPID С PRI NI ADDR SZ WCHAN  TTY   TIME     CMD

000 S 500 1259 1254 0  75  0 -   710 wait4  pts/2 00:00:00 bash

000 S 500 1262 1251 0  75  0 -   714 wait4  pts/1 00:00:00 bash

000 S 500 1313 1262 0  75  0 -  2762 schedu pts/1 00:00:00 emacs

000 S 500 1362 1262 2  80  0 -   789 schedu pts/1 00:00:00 oclook

000 R 500 1363 1262 0  81  0 -   782 -      pts/1 00:00:00 ps

Как видно из списка, программа

oclock

nice

$ nice oclock &

то получила бы значение

nice

$ renice 10 1362

1362: old priority 0, new priority 10

программа

oclock

ps

$ ps -l

F   S UID  PID PPID С PRI NI ADDR SZ WCHAN  TTY   TIME     CMD

000 S 500 1259 1254 0  75  0 -   710 wait4  pts/2 00:00:00 bash

000 S 500 1262 1251 0  75  0 -   714 wait4  pts/1 00:00:00 bash

000 S 500 1313 1262 0  75  0 -  2762 schedu pts/1 00:00:00 emacs

000 S 500 1362 1262 0  90 10 -   789 schedu pts/1 00:00:00 oclock

000 R 500 1365 1262 0  81  0 -   782 -      pts/1 00:00:00 ps

Столбец состояния теперь также содержит

N

nice

$ ps х

PID  TTY   STAT TIME COMMAND

1362 pts/1 SN   0:00 oclock

Поле

PPID

ps

init

Планировщик процессов ОС Linux решает, какому процессу разрешить выполнение, на основе приоритета. Конкретные реализации конечно отличаются, но высокоприоритетные процессы выполняются чаще. В некоторых случаях низкоприоритетные процессы не выполняются совсем, если высокоприоритетные процессы готовы к выполнению.

Применив библиотечную функцию

system

#include <stdlib.h>

int system(const char *string);

Функция

system

$ sh -с string

Функция

system

system

Выполните упражнение 11.1.

Вы можете использовать

system

ps

#include <stdlib.h>

#include <stdio.h>

int main() {

 printf("Running ps with system\n");

 system("ps ax");

 printf("Done \n");

 exit(0);

}

Когда вы откомпилируете и выполните программу system1.с, то получите вывод, похожий на приведенный далее:

$ ./system1

Running ps with system

 PID TTY   STAT TIME COMMAND

   1 ?     Ss   0:03 init [5]

...

1262 pts/1 Ss   0:00 /bin/bash

1273 pts/2 S    0:00 su -

1274 pts/2 S+   0:00 -bash

1463 pts/2 SN   0:00 oclock

1465 pts/1 S    0:01 emacs Makefile

1480 pts/1 S+   0:00 ./system1

1481 pts/1 R+    0:00 ps ax

Done.

Поскольку функция

system

system("ps ах &");

Когда вы откомпилируете и выполните эту версию программы, то получите следующий вывод:

$ ./system2

Running ps with system

 PID TTY  STAT TIME COMMAND

   1 ?    S    0:03 init [5]

 ...

Done.

$ 1274 pts/2 3+ 0:00 -bash

1463 pts/2 SN  0:00 oclock

1465 pts/1 S   0:01 emacs Makefile

1484 pts/1 R   0:00 ps ax

Как это работает

В первом примере программа вызывает функцию

system

ps ах

ps

ps

system

system

system

Во втором примере вызов функции

system

ps

$ ps ах &

Далее программа system2 выводит

Done.

ps

ps

system2

exec

Примечание

Вообще применение функции

system

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

system

.

Существует целое семейство родственных функций, сгруппированных под заголовком

exec

exec

path

file

exec

exec

system

#include <unistd.h>

char **environ;

int execl(const char *path, const char *arg0, ..., (char *)0);

int execlp(const char *file, const char *arg0, ..., (char *)0);

int execle(const char *path, const char *arg0, ..., (char *)0,

 char *const envp[]);

int execv(const char *path, char *const argv[]);

int execvp(const char *file, char *const argv[]);

int execve(const char *path, char *const argv[], char *const envp[]);

Эти функции делятся на два вида.

execl

execlp

execle

null

execv

execvp

argv

main

Эти функции реализованы, как правило, с использованием

execve

Функции, имена которых содержат суффикс

p

PATH

Передать значение окружению программы может глобальная переменная

environ

execle

execve

Если вы хотите применить функцию

exec

ps

exec

#include <unistd.h>

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

/* Учтите, что для argv[0] необходимо имя программы */

char *const ps_argv[] = {"ps", "ax", 0};

/* He слишком полезный пример окружения */

char *const ps_envp[] = {"PATH=/bin:/usr/bin", "TERM=console", 0};

/* Возможные вызовы функций exec */

execl("/bin/ps", "ps", "ax", 0);

/* предполагается, что ps в /bin */

execlp("ps", "ps", "ax", 0);

/* предполагается, что /bin в PATH */

execle("/bin/ps", "ps", "ax", 0, ps_envp);

/* передается свое окружение */

execv("/bin/ps", ps_argv);

execvp("ps", ps_argv);

execve("/bin/ps", ps_argv, ps_envp);

А теперь выполните упражнение 11.2.

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

execlp

#include <unistd.h>

#include <stdio.h>

#include <stdlib.h>

int main() {

 printf("Running ps with execlp\n");

 execlp("ps", "ps", "ax", 0);

 printf("Done.\n");

 exit(0);

}

Когда вы выполните эту программу, рехес.с, то получите обычный вывод команды

ps

Done

рехес

$ ./рехес

Running ps with execlp

 PID TTY   STAT TIME COMMAND

1    ?     S    0:03 init [5]

...

1262 pts/1 Ss   0:00 /bin/bash

1273 pts/2 S    0:00 su -

1274 pts/2 S+   0:00 -bash

1463 pts/1 SN   0:00 oclock

1465 pts/1 S    0:01 emacs Makefile

1514 pts/1 R+   0:00 ps ax

Как это работает

Программа выводит первое сообщение и затем вызывает функцию

execlp

PATH

ps

рехес

$ ps ax

Когда

ps

рехес

nice

exec

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

exec

ARG_MAX

ARG_MAX

Функции

exec

errno

exec

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

FD_CLOEXEC

fcntl

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

init

exec

Создать новый процесс можно с помощью вызова

fork

exec

fork

#include <sys/types.h>

#include <unistd.h>

pid_t fork(void);

Как видно из рис. 11.2, вызов

fork

fork

Рис. 11.2 

Если вызов

fork

CHILD_MAX

errno

EAGAIN

errno

ENOMEM

Далее приведен фрагмент типичного программного кода, использующего вызов

fork

pid_t new_pid;

new_pid = fork();

switch(new_pid) {

case -1:

 /* Ошибка */

 break;

case 0:

 /* Мы — дочерний процесс */

 break;

default:

 /* Мы — родительский процесс */

 break;

}

Выполните упражнение 11.3.

Давайте рассмотрим простой пример fork1.с:

#include <sys/types.h>

#include <unistd.h>

#include <stdio.h>

#include <stdlib.h>

int main() {

 pid_t pid;

 char* message;

 int n;

 printf("fork program starting\n");

 pid = fork();

 switch(pid) {

 case -1:

  perror("fork failed");

  exit(1);

 case 0:

  message = "This is the child";

  n = 5;

  break;

 default:

  message = "This is the parent";

  n = 3;

  break;

 }

 for (; n > 0; n--) {

  puts(message);

  sleep(1);

 }

 exit(0);

}

Эта программа выполняет два процесса. Дочерний процесс создается и выводит пять раз сообщение. Исходный процесс (родитель) выводит сообщение только три раза. Родительский процесс завершается до того, как дочерний процесс выведет все свои сообщения, поэтому в вывод попадает очередное приглашение командной оболочки.

$ ./fork1

fork program starting

This is the child

This is the parent

This is the parent

This is the child

This is the parent

This is the child

$ This is the child

This is the child

Как это работает

Когда вызывается

fork

fork

Когда вы запускаете дочерний процесс с помощью вызова

fork

wait

#include <sys/types.h>

#include <sys/wait.h>

pid_t wait(int *stat_loc);

Системный вызов

wait

main

exit

stat_loc

Интерпретировать информацию о состоянии процесса можно с помощью макросов, описанных в файле sys/wait.h и приведенных в табл. 11.2.

Таблица 11.2

Выполните упражнение 11.4.

В этом упражнении вы слегка измените программу, чтобы можно было подождать и проверить код состояния дочернего процесса. Назовите новую программу wait.c.

#include <sys/types.h>

#include <sys/wait.h>

#include <unistd.h>

#include <stdio.h>

#include <stdlib.h>

int main() {

 pid_t pid;

 char* message;

 int n;

 int exit_code;

 printf("fork program starting\n");

 pid = fork();

 switch(pid) {

 case -1:

  perror("fork failed");

  exit(1);

 case 0:

  message = "This is the child";

  n = 5;

  exit_code = 37;

  break;

 default:

  message = "This is the parent";

  n = 3;

  exit_code = 0;

  break;

 }

 for (; n > 0; n--) {

  puts(message);

  sleep(1);

 }

Следующий фрагмент программы ждет окончания дочернего процесса:

 if (pid != 0) {

  int stat_val;

  pid_t child_pid;

  child_pid = wait(&stat_val);

  printf("Child has finished: PID = %d\n", child_pid);

  if (WIFEXITED(stat_val))

   printf("Child exited with code %d\n", WEXITSTATUS(stat_val));

  else printf("Child terminated abnormally\n");

 }

 exit(exit_code);

}

Когда вы выполните эту программу, то увидите, что родительский процесс ждет дочерний:

$ ./wait

fork program starting

This is the child

This is the parent

This is the parent

This is the child

This is the parent

This is the child

This is the child

This is the child

Child has finished: PID = 1582

Child exited with code 37

$

Как это работает

Родительский процесс, получивший ненулевое значение, возвращенное из вызова

fork

wait

exit

wait

Применение вызова

fork

wait

wait

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

fork

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

switch (pid) {

case -1:

 perror("fork failed");

 exit(1);

case 0:

 message = "This is the child";

 n = 3;

 break;

default:

 message = "This is the parent";

 n = 5;

 break;

}

Как это работает

Если вы выполните только что приведенную программу с помощью команды

./fork2 &

ps

<zombie>

<defunct>

$ ps -аl

  F S UID  PID PPID С PRI NI ADDR SZ WCHAN  TTY   TIME     CMD

004 S   0 1273 1259 0  75  0 -   589 wait4  pts/2 00:00:00 su

000 S   0 1274 1273 0  75  0 -   731 schedu pts/2 00:00:00 bash

000 S 500 1463 1262 0  75  0 -   788 schedu pts/1 00:00:00 oclock

000 S 500 1465 1262 0  75  0 -  2569 schedu pts/1 00:00:01 emacs

000 S 500 1603 1262 0  75  0 -   313 schedu pts/1 00:00:00 fork2

003 Z 500 1604 1603 0  75  0 -     0 do_exi pts/1 00:00:00 fork2 <defunct>

000 R 500 1605 1262 0  81  0 -   781 -      pts/1 00:00:00 ps

Если родительский процесс завершится необычно, дочерний процесс автоматически получит в качестве родителя процесс с PID, равным 1 (init). Теперь дочерний процесс — зомби, который уже не выполняется, но унаследован процессом

init

init

Есть еще один системный вызов, который можно применять для ожидания дочернего процесса. Он называется

waitpid

#include <sys/types.h>

#include <sys/wait.h>

pid_t waitpid(pid_t pid, int *stat_loc, int options);

Аргумент

pid

waitpid

wait

stat_loc

options

waitpid

WNOHANG

waitpid

wait

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

waitpid(child_pid, (int *)0, WNOHANG);

Он вернет ноль, если дочерний процесс не завершился и не остановлен, или

child_pid

errno

errno

ECHILD

EINTR

options

EINVAL

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

fork

exec

Далее приведена программа очень простой фильтрации upper.c, которая читает ввод и преобразует строчные буквы в прописные:

#include <stdio.h>

#include <ctype.h>

#include <stdlib.h>

int main() {

 int ch;

 while ((ch = getchar()) != EOF) {

  putchar(toupper(ch));

 }

 exit(0);

}

Когда вы выполните программу, она сделает то, что и ожидалось:

$ ./upper

hello THERE

HELLO THERE

^D

$

Вы, конечно, можете применить ее для преобразования символов файла, используя перенаправление, применяемое командной оболочкой:

$ cat file.txt

this is the file, file.txt, it is all lower case.

$ ./upper < file.txt

THIS IS THE FILE, FILE.TXT, IT IS ALL LOWER CASE.

Что если вы хотите применить этот фильтр из другой программы? Программа useupper.c принимает имя файла как аргумент и откликается сообщением об ошибке при некорректном вызове:

#include <unistd.h>

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char *argv[]) {

 char *filename;

 if (argc != 2) {

  fprintf (stderr, "usage: useupper file\n");

  exit(1);

 }

 filename = argv[1];

Вы повторно открываете стандартный ввод, снова при этом проверяете наличие любых ошибок, а затем применяете функцию

execl

 if (!freopen(filename, "r", stdin)) {

  fprintf(stderr, "could not redirect stdin from file %s\n", filename);

  exit(2);

 }

 execl("./upper", "upper", 0);

He забудьте, что

execl

 perror("could not exec ./upper");

 exit(3);

}

Как это работает

Когда вы выполняете эту программу, ей можно передать файл для преобразования в прописные буквы. Работа делается программой upper, которая не обрабатывает аргументы с именами файлов. Обратите внимание на то, что вам не нужен исходный код программы upper; таким способом можно запустить любую исполняемую программу.

$ ./useupper file.txt

THIS IS THE FILE, FILE.TXT, IT IS ALL LOWER CASE.

Программа useupper применяет

freopen

execl

execl

$ ./upper < file.txt

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

Существует класс процесса, именуемый потоком (thread), который доступен во многих системах UNIX и Linux. Несмотря на то, что потоки трудно, программировать, они могут быть очень важны для некоторых приложений, таких как многопоточные серверы баз данных. Программирование потоков в Linux (и вообще в UNIX) не так распространено, как применение множественных процессов, поскольку процессы Linux очень легко применять и программирование множественных взаимодействующих процессов гораздо легче программирования потоков. Потоки обсуждаются в главе 12.

Сигнал — это событие, генерируемое системами UNIX и Linux в ответ на некоторую ситуацию, получив сообщение о котором процесс, в свою очередь, может предпринять какое-то действие. Мы применяем термин "возбуждать" (raise) для обозначения генерации сигнала и термин "захватывать" (catch) для обозначения получения или приема сигнала. Сигналы возбуждаются некоторыми ошибочными ситуациями, например нарушениями сегментации памяти, ошибками процессора при выполнении операций с плавающей точкой или некорректными командами. Они генерируются командной оболочкой и обработчиками терминалов для вызова прерываний и могут явно пересылаться от одного процесса к другому как способ передачи информации или коррекции поведения. Во всех этих случаях программный интерфейс один и тот же. Сигналы могут возбуждаться, улавливаться и соответственно обрабатываться или (по крайней мере, некоторые) игнорироваться.

Имена сигналов задаются с помощью включенного заголовочного файла signal.h. Они начинаются с префикса

SIG

Таблица 11.3

*Могут быть также предприняты действия, зависящие от конкретной реализации.

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

К дополнительным относятся сигналы, приведенные в табл. 11.4.

Таблица 11.4

Сигнал

SIGCHLD

SIGCONT

Чуть позже мы рассмотрим более подробно первую группу сигналов. Пока же достаточно знать, что если командная оболочка и драйвер терминала нормально настроены, ввод символа прерывания (обычно от нажатия комбинации клавиш <Ctrl>+<C>) с клавиатуры приведет к отправке сигнала

SIGINT

Если вы хотите отправить сигнал не текущей приоритетной задаче, а другому процессу, используйте команду

kill

$ kill -HUP 512

Удобный вариант команды

kill

killall

inetd

$ killall -HUP inetd

Программы могут обрабатывать сигналы с помощью библиотечной функции

signal

#include <signal.h>

void (*signal(int sig, void (*func)(int)))(int);

Это довольно сложное объявление говорит о том, что

signal

sig

func

sig

func

int

void

□

SIG_IGN

□

SIG_DFL

Пример сделает все понятным. В упражнении 11.7 вы напишете программу ctrlc.c, которая реагирует на нажатие комбинации клавиш <Ctrl>+<C> вместо обычного завершения выводом соответствующего сообщения. Повторное нажатие <Ctrl>+<C> завершает программу.

Функция

ouch

sig

#include <signal.h>

#include <stdio.h>

#include <unistd.h>

void ouch(int sig) {

 printf("OUCH! - I got signal %d\n", sig);

 (void)signal(SIGINT, SIG_DFL);

}

Функция

main

SIGINT

int main() {

 (void)signal(SIGINT, ouch);

 while(1) {

  printf("Hello World!\n");

  sleep(1);

 }

}

Ввод комбинации клавиш <Ctrl>+<C> (отображается как

^C

SIGINT

$ ./ctrlcl

Hello World!

Hello World!

Hello World!

Hello World!

^C

OUCH! - I got signal 2

Hello World!

Hello World!

Hello World!

Hello World!

^C

$

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

SIGINT

Примечание

Вызывать из обработчика сигнала все функции, например,

printf

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

main

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

Как это работает

Программа устроена так, что, когда вы задаете сигнал

SIGINT

ouch

ouch

SIGINT

Если вы хотите сохранить обработчик сигнала и продолжать реагировать на комбинацию клавиш <Ctrl>+<C>, вам придется восстановить его, вызвав функцию

signal

Примечание

Мы не рекомендуем вам пользоваться функцией

signal

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

sigaction

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

Функция

signal

SIG_ERR

errno

SIGKILL

errno

EINVAL

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

kill

#include <sys/types.h>

#include <signal.h>

int kill(pid_t pid, int sig);

Функция

kill

sig

pid

Функция

kill

errno

errno

EINVAL

EPERM

ESRCH

Сигналы предоставляют полезное средство, именуемое будильником или сигналом тревоги. Вызов функции

alarm

SIGALRM

#include <unistd.h>

unsigned int alarm(unsigned int seconds);

Вызов

alarm

SIGALRM

seconds

alarm

alarm

alarm

Для того чтобы увидеть как работает функция

alarm

fork

sleep

signal

В программе alarm.c первая функция,

ding

#include <sys/types.h>

#include <signal.h>

#include <stdio.h>

#include <unistd.h>

#include <stdlib.h>

static int alarm_fired = 0;

void ding(int sig) {

 alarm_fired = 1;

}

В функции

main

SIGALRM

int main() {

 pid_t pid;

 printf("alarm application starting\n");

 pid = fork();

 switch(pid) {

 case -1:

  /* Аварийное завершение */

  perror("fork failed");

  exit(1);

 case 0:

  /* Дочерний процесс */

  sleep(5);

  kill(getppid(), SIGALRM);

  exit(0);

 }

Родительский процесс устроен так, что перехватывает сигнал

SIGALRM

signal

 /* Если мы оказались здесь, то мы — родительский процесс */

 printf("waiting for alarm to go off\n");

 (void)signal(SIGALRM, ding);

 pause();

 if (alarm_fired) printf("Ding!\n");

 printf("done\n");

 exit(0);

}

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

$ ./alarm

alarm application starting

waiting for alarm to go off

<5 second pause>

Ding!

done $

В этой программе вводится новая функция

pause

#include <unistd.h>

int pause(void);

Функция возвращает -1 (если следующий полученный сигнал не вызвал завершения программы) с переменной

errno

EINTR

sigsuspend

Как это работает

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

fork

SIGALRM

SIGALRM

printf

Применение сигналов и приостановка выполнения — важные составляющие программирования в ОС Linux. Это означает, что программа необязательно должна выполняться все время. Вместо того чтобы долго работать в цикле, проверяя, не произошло ли событие, она может ждать его наступления. Это особенно важно в многопользовательской среде, где процессы совместно используют один процессор, и такой вид деятельного ожидания оказывает большое влияние на производительность системы. Особая проблема, связанная с сигналами, заключается в том, что вы никогда не знаете наверняка, что произойдет, если сигнал появится в середине системного вызова? (Ответ весьма неудовлетворительный: все зависит от ситуации.) Вообще следует беспокоиться только о "медленных" системных вызовах, таких как считывание с терминала, когда системный вызов может вернуться с ошибкой, если сигнал появится во время его пребывания в режиме ожидания. Если вы начнете применять сигналы в своих программах, нужно учитывать, что некоторые системные вызовы могут закончиться аварийно, если сигнал создаст ошибочную ситуацию, которую вы могли не принимать во внимание до того, как добавили обработку сигналов.

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

Мы рассмотрели подробно возбуждение и перехват сигналов с помощью

signal

sigaction

#include <signal.h>

int sigaction<int sig, const struct sigaction *act, struct sigaction *oact);

Структура

sigaction

sig

void (*)(int)sa_handler /* функция, SIG_DFL или SIG_IGN */

sigset_t sa_mask        /* сигналы, заблокированные для sa_handler */

int sa_flags            /* модификаторы действий сигнала */

Функция

sigaction

sig

oact

null

sigaction

oact

act

null

sigaction

act

null

Как и функция

signal

sigaction

errno

EINVAL

В структуре

sigaction

act

sa_handler

sig

func

signal

SIG_IGN

SIG_DFL

sa_handler

Поле

sa_mask

sa_handler

sa_mask

Однако сигналы, захватываемые обработчиками, заданными в структуре

sigaction

sa_flags

SA_RESETHAND

signal

sigaction

sigaction

signal

Внесите приведенные далее изменения, так чтобы сигнал

SIGINT

sigaction

#include <signal.h>

#include <stdio.h>

#include <unistd.h>

void ouch(int sig) {

 printf("OUCH! - I got signal %d\n", sig);

}

int main() {

 struct sigaction act;

 act.sa_handler = ouch;

 sigemptyset(&act.sa_mask);

 act.sa_flags = 0;

 sigaction(SIGINT, &act, 0);

 while (1) {

  printf("Hello World!\n");

  sleep(1);

 }

}

Когда вы выполните эту версию программы, то всегда будете получать сообщение при нажатии комбинации клавиш <Ctrl>+<C>, поскольку

SIGINT

sigaction

SIIGQUIT

$ ./ctrlc2

Hello World!

Hello World!

Hello World!

^C

OUCH! - I got signal 2

Hello World!

Hello World!

^C

OUCH! - I got signal 2

Hello World!

Hello World!

^\

Quit

$

Как это работает

Программа вместо функции

signal

sigaction

ouch

SIGINT

sigaction

sigemptyset

Примечание

После выполнения программы вы можете обнаружить дамп ядра (в файле core). Его можно безбоязненно удалить.

В заголовочном файле signal.h определены тип

sigset_t

sigaction

#include <signal.h>

int sigaddset(sigset_t *set, int signo);

int sigemptyset(sigset_t *set);

int sigfillset(sigset_t *set);

int sigdelset(sigset_t *set, int signo);

Приведенные функции выполняют операции, соответствующие их названиям,

sigemptyset

sigfillset

sigaddset

sigdelset

signo

errno

EINVAL

Функция

sigismember

errno

EINVAL

#include <signal.h>

int sigismember(sigset_t *set, int signo);

Маска сигналов процесса задается и просматривается с помощью функции

sigprocmask

#include <signal.h>

int sigprocmask(int how, const sigset_t *set, sigset_t *oset);

Функция

sigprocmask

how

set

null

oset

Аргумент

how

□

SIG_BLOCK

set

□

SIG_SETMASK

set

□

SIG_UNBLOCK

set

Если аргумент

set

null

how

oset

Если функция

sigprocmask

how

errno

EINVAL

Если сигнал заблокирован процессом, он не будет доставлен, но останется ждать обработки. Программа может определить с помощью функции

sigpending

#include <signal.h>

int sigpending(sigset_t *set);

Она записывает множество сигналов, заблокированных от доставки и ждущих обработки, в множество сигналов, на которое указывает аргумент

set

errno

С помощью функции

sigsuspend

pause

#include <signal.h>

int sigsuspend(const sigset_t *sigmask);

Функция

sigsuspend

sigmask

sigsuspend

sigsuspend

errno

EINTR

Поле

sa_flags

sigaction

sigaction

Таблица 11.5

Флаг

SA_RESETHAND

Многие системные вызовы, которые использует программа, прерываемые, т.е. при получении сигнала они вернутся с ошибкой и переменная

errno

EINTR

sa_flags

sigaction

SA_RESTART

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

SA_NODEFER

Функция обработки сигнала может быть прервана в середине и вызвана снова чем-нибудь еще. Когда вы возвращаетесь к первому вызову функции, крайне важно, чтобы она все еще действовала корректно. Она должна быть не просто рекурсивной (вызывающей саму себя), а реентерабельной (в нее можно войти и выполнить ее снова). Подпрограммы ядра, обслуживающие прерывания и имеющие дело с несколькими устройствами одновременно, должны быть реентерабельными, поскольку высокоприоритетное прерывание может "войти" в тот код, который выполняется.

Функции, которые безопасно вызываются в обработчике сигнала и в стандарте X/Open гарантированно описанные либо как реентерабельные, либо как самостоятельно не возбуждающие сигналов, перечислены в табл. 11.6.

Все функции, не включенные в табл. 11.6, следует считать небезопасными в том, что касается сигналов.

Таблица 11.6

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

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

_exit

exit

wait

waitpid

Таблица 11.7

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

Таблица 11.8

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

Таблица 11.9

Сигнал

SIGCONT

SIGCHLD

Таблица 11.10

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

init