Linux программирование в примерах

Роббинс Арнольд

Часть 2

Процессы, IPC и интернационализация

 

 

Глава 9

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

 

Как мы говорили в главе 1 «Введение», если бы нужно было резюмировать Unix (а следовательно, и Linux) в трёх словах, это были бы «файлы и процессы». Теперь, когда мы увидели, как работать с файлами и каталогами, время взглянуть на оставшуюся часть утверждения: процессы. В частности, мы исследуем, как создаются и управляются процессы, как они взаимодействуют с открытыми файлами и как они могут взаимодействовать друге другом. Последующие главы исследуют сигналы — грубый способ дать возможность одному процессу (или ядру) сообщить другому о том, что произошло некоторое событие — и проверку прав доступа.

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

 

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

 

В отличие от многих предшествующих и последующих операционных систем, создание процессов в Unix задумывалось (и было сделано) дешевым. Более того, Unix разделяет идеи «создания нового процесса» и «запуска данной программы в процессе». Это было элегантное проектное решение, которое упрощает многие операции.

 

9.1.1. Создание процесса:

fork()

 

Первым шагом в запуске новой программы является вызов fork():

#include /* POSIX */

#include

pid_t fork(void);

Использование fork() просто. Перед вызовом один процесс, который мы называем родительским, является запущенным. Когда fork() возвращается, имеется уже два процесса: родительский и порожденный (child).

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

Отрицательное

Если была ошибка, fork() возвращает -1, а новый процесс не создается. Работу продолжает первоначальный процесс.

Нулевое

В порожденном процессе fork() возвращает 0.

Положительное

В родительском процессе fork() возвращает положительный идентификационный номер (PID) порожденного процесса.

Код шаблона для создания порожденного процесса выглядит следующим образом:

pid_t child;

if ((child = fork()) < 0)

 /* обработать ошибку */

else if (child == 0)

 /* это новый процесс */

else

 /* это первоначальный родительский процесс */

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

На языке Unix, помимо названия системного вызова, слово «fork» является и глаголом, и существительным. Мы можем сказать, что «один процесс ответвляет другой», и что «после разветвления работают два процесса». (Думайте «развилка (fork) на дороге», а не «вилка (fork), нож и ложка».)

 

9.1.1.1. После

fork()

: общие и различные атрибуты

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

• Окружение, см. раздел 2.4 «Окружение».

• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 5.3.1 «Базовое чтение каталогов».

• Установки umask; см. раздел 4.6 «Создание файлов».

• Текущий рабочий каталог; см раздел 8.4.1 «Смена каталога: chdir() и fchdir().

• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога: chroot()».

• Текущий приоритет (иначе называемый «значение nice»; вскоре мы это обсудим; см раздел 9.1.3 «Установка приоритета процесса: nice()»).

• Управляющие терминалы. Это устройство терминала (физическая консоль или окно эмулятора терминала), которому разрешено посылать процессу сигналы (такие, как CTRL-Z для прекращения выполняющихся работ). Это обсуждается далее в разделе 9.2.1 «Обзор управления работой».

• Маска сигналов процесса и расположение всех текущих сигналов (еще не обсуждалось; см. главу 10 «Сигналы»).

• Реальный, эффективный и сохраненный ID пользователя, группы и набора дополнительных групп (еще не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы»).

Помимо возвращаемого значения fork() два процесса различаются следующим образом:

• У каждого есть уникальный ID процесса и ID родительского процесса (PID и PPID) Они описаны в разделе 9.1.2 «Идентификация процесса: getpid() и getppid()».

• PID порожденного процесса не будет равняться ID любой существующей группы процессов (см. раздел 9.2 «Группы процессов»).

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

• Любые сигналы, которые были ожидающими в родительском процессе, в порожденном сбрасываются, также как ожидающие аварийные сигналы и таймеры. (Мы еще не рассматривали эти темы; см. главу 10 «Сигналы» и раздел 14.3.3 «Интервальные таймеры: setitimer() и getitimer()».)

• Блокировки файлов в родительском процессе не дублируются в порожденном (также еще не обсуждалось; см. раздел 14.2 «Блокировка файлов»).

 

9.1.1.2. Разделение дескрипторов файлов

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

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

Рис. 9.1. Разделение дескрипторов файлов

Рисунок отображает внутренние структуры данных ядра. Ключевой структурой данных является таблица файлов. Каждый элемент ссылается на открытый файл. Помимо других учетных данных, таблица файлов содержит текущее положение (смещение чтения/записи) в файле. Оно устанавливается либо автоматически каждый раз при чтении или записи файла, либо непосредственно через lseek() (см. раздел 4.5 «Произвольный доступ: перемещения внутри файла»).

Дескриптор файла, возвращенный функциями open() или creat(), действует как индекс имеющегося в каждом процессе массива указателей на таблицу файлов. Размер этого массива не превышает значение, возвращенное getdtablesize() (см. раздел 4.4.1 «Понятие о дескрипторах файлов»).

На рис. 9.1 показаны два процесса, разделяющие стандартный ввод и стандартный вывод; для каждого из процессов указаны одни и те же элементы в таблице файлов. Поэтому, когда процесс 45 (порожденный) осуществляет read(), общее смещение обновляется; следующий раз, когда процесс 42 (родитель) осуществляет read(), он начинает с позиции, в которой закончила чтение read() процесса 45.

Это легко можно видеть на уровне оболочки:

$ cat data /* Показать содержание демонстрационного файла */

line 1

line 2

line 3

line 4

$ ls -l test1 ; cat test1 /* Режим и содержание тестовой программы */

-rwxr-xr-x 1 arnold devel 93 Oct 20 22:11 test1

#! /bin/sh

read line ; echo p: $line /* Прочесть строку в родительской оболочке,

                             вывести ее */

( read line ; echo с: $line ) /* Прочесть строку в порожденной оболочке,

                                 вывести ее */

read line ; echo p: $line /* Прочесть строку в родительской оболочке,

                             вывести ее */

$ test1 < data /* Запустить программу */

p: line 1 /* Родитель начинает сначала */

c: line 2 /* Порожденный продолжает оттуда, где остановился родитель */

p: line 3 /* Родитель продолжает оттуда, где остановился порожденный */

Первая исполняемая строка test1 читает из стандартного ввода строку, изменяя смещение файла. Следующая строка test1 запускает команды, заключенные между скобками, в подоболочке (subshell). Это отдельный процесс оболочки, созданный — как вы догадались — с помощью fork(). Порожденная подоболочка наследует от родителя стандартный ввод, включая текущее смещение. Этот процесс читает строку и обновляет разделяемое смещение в файле. Когда третья строка, снова в родительской оболочке, читает файл, она начинает там, где остановился порожденный.

Хотя команда read встроена в оболочку, все работает таким же образом и для внешних команд. В некоторых ранних Unix-системах была команда line, которая читала одну строку ввода (по одному символу за раз!) для использования в сценариях оболочки; если бы смещение файла не было разделяемым, было бы невозможно использовать такую команду в цикле.

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

 

9.1.1.3. Разделение дескрипторов файлов и

close()

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

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

Если вам нужно узнать, открыты ли два дескриптора для одного и того же файла, можете использовать fstat() (см. раздел 5.4.2 «Получение сведений о файле») для двух дескрипторов с двумя различными структурами struct stat. Если соответствующие поля st_dev и st_ino равны, это один и тот же файл.

Позже в главе мы завершим обсуждение манипуляций с дескрипторами файлов и таблицей дескрипторов файлов.

 

9.1.2. Идентификация процесса:

getpid()

и

getppid()

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

#include /* POSIX */

#include

pid_t getpid(void);

pid_t getppid(void);

Функции так просты, как выглядят:

pid_t getpid(void) Возвращает PID текущего процесса

pid_t getppid(void)Возвращает PID родителя.

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

Если родительский процесс завершается, порожденный получает нового родителя, init. В этом случае PID родителя будет 1, что является PID init. Такой порожденный процесс называется висячим (orphan). Следующая программа, ch09-reparent.с, демонстрирует это. Это также первый пример fork() в действии:

1  /* ch09-reparent.c --- показывает, что getppid() может менять значения */

2

3  #include

4  #include

5  #include

6  #include

7

8  /* main --- осуществляет работу */

9

10 int main(int argc, char **argv)

11 {

12  pid_t pid, old_ppid, new_ppid;

13  pid_t child, parent;

14

15  parent = getpid(); /* перед fork() */

16

17  if ((child = fork()) < 0) {

18   fprintf(stderr, "%s: fork of child failed: %s\n",

19    argv[0], strerror(errno));

20   exit(1);

21  } else if (child == 0) {

22   old_ppid = getppid();

23   sleep(2); /* см. главу 10 */

24   new_ppid = getppid();

25  } else {

26   sleep(1);

27   exit(0); /* родитель завершается после fork() */

28  }

29

30  /* это выполняет только порожденный процесс */

31  printf("Original parent: %d\n", parent);

32  printf("Child: %d\n", getpid());

33  printf("Child's old ppid: %d\n", old_ppid);

34  printf("Child's new ppid: %d\n", new_ppid);

35

36  exit(0);

37 }

Строка 15 получает PID начального процесса, используя getpid(). Строки 17–20 создают порожденный процесс, проверяя по возвращении ошибки.

Строки 21–24 выполняются порожденным процессом: строка 22 получает PPID. Строка 23 приостанавливает процесс на две секунды (сведения о sleep() см в разделе 10.8.1 «Аварийные часы: sleep(), alarm() и SIGALRM»), а строка 24 снова получает PPID.

Строки 25–27 исполняются в родительском процессе. Строка 26 задерживает родителя на одну секунду, давая порожденному процессу достаточно времени для осуществления первого вызова getppid(). Строка 27 завершает родителя.

Строки 31–34 выводят значения. Обратите внимание, что переменная parent, которая была установлена до разветвления, сохраняет свое значение в порожденном процессе. После порождения у двух процессов идентичные, но независимые копии адресного пространства. Вот что происходит при запуске программы:

$ ch09-reparent /* Запуск программы */

$ Original parent: 6582 /* Программа завершается: приглашение оболочки

                           и вывод порожденного процесса */

Child: 6583

Child's old ppid: 6582

Child's new ppid: 1

Помните, что обе программы выполняются параллельно. Графически это изображено на рис. 9.2.

Рис. 9.2. Два параллельно исполняющихся процесса после разветвления

ЗАМЕЧАНИЕ . Использование sleep() , чтобы заставить один процесс пережить другой, работает в большинстве случаев. Однако, иногда случаются ошибки, которые трудно воспроизвести и трудно обнаружить. Единственным способом гарантировать правильное поведение является явная синхронизация с помощью wait() или waitpid() , которые описываются далее в главе (см. раздел 9.1.6.1 «Использование функций POSIX: wait() и waitpid() »).

 

9.1.3. Установка приоритетов процесса:

nice()

 

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

Linux, как и Unix, обеспечивает вытесняющую многозадачность. Это означает, что ядро может вытеснить процесс (приостановить его), если настало время дать возможность поработать другому процессу. Приоритет длительное время работающих процессов (например, процессов, выполняющих интенсивные вычисления), снижается в конце их кванта времени, поэтому они дают шанс другим процессам получить время процессора. Сходным образом, процессам, длительное время бездействовавшим в ожидании завершения ввода/вывода (таким, как интерактивный текстовый редактор), приоритет повышается, так что они могут ответить на ввод/вывод, когда он происходит. Короче, ядро гарантирует, что все процессы, усредненные по времени, получают свою «справедливую долю» времени процессора. Повышение и понижение приоритетов является частью этого процесса.

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

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

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

Значение относительного приоритета является лишь одним фактором в уравнении, используемом ядром для вычисления приоритета; это не значение самого приоритета, которое изменяется с течением времени на основе поведения процесса и состояния других процессов системы. Для изменения значения относительного приоритета используется системный вызов nice():

#include /* XSI */

int nice(int inc);

Значение относительного приоритета по умолчанию равно 0. Разрешен диапазон значений от -20 до 19. Это требует некоторой привычки. Чем более отрицательное значение, тем выше приоритет процесса: -20 является наивысшим приоритетом (наименьшая приятность), а 19 — наинизшим приоритетом (наибольшая приятность)

Аргумент inc является приращением, на который надо изменить значение приоритета. Для получения текущего значения, не изменяя его, используйте 'nice(0)'. Если результат 'текущий_относительный_приоритет + inc' выйдет за пределы от -20 до 19, система принудительно включит его в этот диапазон.

Возвращаемое значение является новым значением относительного приоритета или -1, если возникла ошибка. Поскольку -1 также является действительным значением относительного приоритета, при вызове nice() следует сначала явным образом установить errno в ноль, а затем проверить его насчет имевшихся проблем:

int niceval;

int inc = /* любое значение */;

errno = 0;

if ((niceval = nice(inc)) < 0 && errno != 0) {

 fprintf(stderr, "nice(%d) failed: %s\n", inc, strerror(errno));

 /* другое восстановление */

}

Этот пример может завершиться неудачей, если в inc отрицательное значение, а процесс не запущен как root.

 

9.1.3.1. POSIX против действительности

Диапазон значений относительного приоритета от -20 до 19, которые использует Linux, имеет исторические корни; он ведет начало по крайней мерее V7. POSIX выражает состояние менее прямым языком, что дает возможность большей гибкости, сохраняя в то же время историческую совместимость. Это также затрудняет чтение и понимание стандарта, вот почему вы и читаете эту книгу. Итак, вот как описывает это POSIX

Во-первых, значение относительного приоритета процесса, поддерживаемое системой, колеблется от 0 до '(2 * NZERO) - 1'. Константа NZERO определена в и должна равняться по крайней мере 20. Это дает диапазон 0–39.

Во-вторых, как мы описывали, сумма текущего значения относительного приоритета и приращение incr загоняются в этот диапазон.

В заключение, возвращаемое nice() значение является значением относительного приоритета процесса минус NZERO. При значении NZERO 20 это дает первоначальный диапазон от -20 до 19, который мы описали вначале.

Результатом является то, что возвращаемое nice() значение в действительности изменяется от '-NZERO' до 'NZERO-1', и лучше всего писать свой код в терминах этой именованной константы. Однако, на практике трудно найти систему, в которой NZERO не было бы равно 20.

 

9.1.4. Запуск новой программы: семейство

exec()

 

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

#include /* POSIX */

int execve(const char *filename, /* Системный вызов */

char *const argv[], char *const envp[]);

int execl(const char *path, const char *arg, ...); /* Оболочки */

int execlp(const char *file, const char *arg, ...);

int execle(const char *path, const char *arg, ..., char *const envp[]);

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

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

Мы ссылаемся на эти функции как на «семейство exec()». Функции с именем exec() нет; вместо этого мы используем это имя для обозначения любой из перечисленных выше функций. Как и в случае с fork(), «exec» используется на языке Unix и в качестве глагола, означающего исполнение (запуск) программы, и в качестве существительного.

 

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

execve()

Простейшей для объяснения функцией является execve(). Она является также лежащим в основе системным вызовом. Другие являются функциями-оболочками, как вскоре будет объяснено.

int execve(const char *filename, char *const argv[],

 char* const envp[]);

filename является именем программы для исполнения. Это может быть именем полного или относительного пути. Файл должен иметь формат исполняемого файла, который понимает ядро. Современные системы используют формат исполняемого файла ELF (Extensible Linking Format — открытый формат компоновки). GNU/Linux распознает ELF и несколько других форматов. С помощью execve() можно исполнять интерпретируемые сценарии, если они используют особую первую строку с именем интерпретатора, начинающуюся с '#!'. (Сценарии, которые не начинаются с '#!', потерпят неудачу.) В разделе 1.1.3 «Исполняемые файлы» представлен пример использования '#!'. argv является стандартным списком аргументов С — массив символьных указателей на строки аргументов, включая значение для использования с argv[0], завершающийся указателем NULL.

envp является окружением для использования новым процессом, с таким же форматом, как глобальная переменная environ (см. раздел 2.4 «Переменные окружения»). В новой программе это окружение становится начальным значением environ.

Программа не должна возвращаться из вызова exec(). Если она возвращается, возникла проблема. Чаще всего либо не существует затребованная программа, либо она существует, но не является исполняемой (значения для errno ENOENT и EACCESS соответственно). Может быть множество других ошибок; см. справочную страницу execve(2).

В предположении, что вызов был успешным, текущее содержимое адресного пространства процесса сбрасывается. (Ядро сначала сохраняет в безопасном месте данные argv и envp.) Ядро загружает для новой программы исполняемый код вместе со всеми глобальными и статическими переменными. Затем ядро инициализирует переменные окружения переданными execve() данными, а далее вызывает процедуру main() новой программы с переданным функции execve() массивом argv. Подсчитывается число аргументов и это значение передается main() в argc.

К этому моменту новая программа запущена. Она не знает (и не может определить), какая программа была в процессе до нее. Обратите внимание, что ID процесса не меняется. Многие другие атрибуты при вызове exec сохраняются; вскоре мы рассмотрим это более подробно.

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

 

9.1.4.2. Функции-оболочки:

execl()

и др.

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

int execl(const char *path, const char *arg, ...)

Первый аргумент, path, является путем к исполняемому файлу. Последующие аргументы, начиная с arg, являются отдельными элементами, которые должны быть помещены в argv. Как и ранее, явным образом должен быть включен argv[0]. Вы должны в качестве последнего аргумента передать завершающий указатель NULL, чтобы execl() смогла определить, где заканчивается список аргументов. Новая программа наследует любые переменные окружения, которые находятся в переменной environ.

int execlp(const char *file, const char *arg, ...)

Эта функция подобна execl(), но она имитирует механизм поиска команд оболочки, разыскивая file в каждом каталоге, указанном в переменной окружения PATH. Если file содержит символ /, этот поиск не осуществляется. Если PATH в окружении не присутствует, execlp() использует путь по умолчанию. В GNU/Linux по умолчанию используется ":/bin:/usr/bin", но в других системах может быть другое значение. (Обратите внимание, что ведущее двоеточие в PATH означает, что сначала поиск осуществляется в текущем каталоге.)

Более того, если файл найден и имеет право доступа на исполнение, но не может быть исполнен из-за того, что неизвестен его формат, execlp() считает, что это сценарий оболочки и запускает оболочку с именем файла в качестве аргумента.

int execle(const char *path, const char *arg, ...,

 char *const envp[])

Эта функция также подобна execl(), но принимает дополнительный аргумент, envp, который становится окружением новой программы. Как и в случае с execl(), вы должны для завершения списка аргументов поместить перед envp указатель NULL.

Вторая группа функций-оболочек принимает массив в стиле argv:

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

Эта функция подобна execve(), но новая программа наследует любое окружение, которое находится в переменной environ текущей программы.

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

Эта функция подобна execv(), но она осуществляет такой же поиск в PATH, как и функция execlp(). Она также переходит на исполнение сценария оболочки, если найденный файл не может быть исполнен непосредственно.

В табл. 9.1 подведены итоги для шести функций exec().

Таблица 9.1. Сводка семейства функций exec() по алфавиту

Функция Поиск пути Окружение пользователя Назначение
execl() Исполняет список аргументов.
execle() Исполняет список аргументов с окружением.
execlp() Исполняет список аргументов с поиском пути
execv() Исполняет с argv
execve() Исполняет с argv и окружением (системный вызов).
execvp() Исполняет с argv и с поиском пути

Функций execlp() и execvp() лучше избегать, если вы не знаете, что переменная окружения PATH содержит приемлемый список каталогов.

 

9.1.4.3. Имена программ и

argv[0]

До сих пор мы все время считали argv[0] именем программы. Мы знаем, что оно может содержать, а может и не содержать символ /, в зависимости от способа вызова программы, если этот символ содержится, это хорошая подсказка к тому, что для вызова программы использовалось имя пути.

Однако, как должно быть ясно к этому времени, то, что argv[0] содержит имя файла, является лишь соглашением. Ничто не может воспрепятствовать передаче вами вызываемой программе в качестве argv[0] произвольной строки. Следующая программа, ch09-run.c, демонстрирует передачу произвольной строки:

1  /* ch09-run.c --- запуск программы с другим именем и любыми аргументами */

2

3  #include

4  #include

5  #include

6

7  /* main --- настроить argv и запустить указанную программу */

8

9  int main(int argc, char **argv)

10 {

11  char *path;

12

13  if (argc < 3) {

14   fprintf(stderr, "usage: %s path arg0 [ arg ... ]\n", argv[0]);

15   exit(1);

16  }

17

18  path = argv[1];

19

20  execv(path, argv + 2); /* skip argv[0] and argv[1] */

21

22  fprintf(stderr, "%s: execv() failed: %s\n", argv[0],

23   strerror(errno));

24  exit(1);

25 }

Первый аргумент является путем к запускаемой программе, а второй аргумент является новым именем для программы (которое большинство утилит игнорируют, кроме сообщений об ошибках); все остальные аргументы передаются вызываемой программе.

Строки 13–16 осуществляют проверку ошибок. Строка 18 сохраняет путь в path Строка 20 осуществляет exec; если программа доходит до строк 22–23, это указывает на ошибку. Вот что происходит при запуске программы:

$ ch09-run /bin/grep whoami foo /* Запустить grep */

a line /* Входная строка не подходит */

a line with foo in it /* Входная строка подходит */

a line with foo in it /* Это выводится */

^D /* EOF */

$ ch09-run nonexistent-program foo bar /* Демонстрация неудачи */

ch09-run: execv() failed: No such file or directory

Следующий пример несколько неестественен: мы заставили ch09-run запустить себя, передав в качестве имени программы 'foo'. Поскольку аргументов для второго запуска недостаточно, она выводит сообщение об использовании и завершается:

$ ch09-run ./ch09-run foo

usage: foo path arg() [ arg ... ]

Хотя она и не очень полезна, ch09-run ясно показывает, что argv[0] не обязательно должен иметь какое-нибудь отношение к файлу, который в действительности запускается.

В System III (примерно в 1980-м) команды cp, ln и mv представляли один исполняемый файл с тремя ссылками с этими именами в /bin. Программа проверяла argv[0] и решала, что она должна делать. Это сохраняло некоторое количество дискового пространства за счет усложнения исходного кода и форсирования выполнения программой действия по умолчанию при запуске с неизвестным именем. (Некоторые современные коммерческие системы Unix продолжают эту практику!) Без явной формулировки причин GNU Coding Standards рекомендует, чтобы программы не основывали свое поведение на своем имени. Одна причина, которую мы видели, состоит в том, что администраторы часто устанавливают GNU версию утилиты наряду со стандартной версией коммерческих систем Unix, используя префикс g: gmake, gawk и т.д. Если такие программы ожидают лишь стандартные имена, они при запуске с другим именем потерпят неудачу.

Сегодня также дисковое пространство дешево; если из одного и того же исходного кода можно построить две почти идентичные программы, лучше это сделать, использовав #ifdef, что у вас есть. Например, grep и egrep имеют значительную часть общего кода, но GNU версия строит два отдельных исполняемых файла.

 

9.1.4.4. Атрибуты, наследуемые

exec()

Как и в случае с fork(), после вызова программой exec сохраняется ряд атрибутов:

• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 3.3.1 «Базовое чтение каталогов». (Сюда не входят файлы, помеченные для закрытия при исполнении (close-on-exec), как описано далее в этой главе; см. раздел 9.4.3.1 «Флаг close-on-exec».)

• Установки umask; см. раздел 4.6 «Создание файлов».

• Текущий рабочий каталог, см. раздел 8.4.1 «Изменение каталога: chdir() и fchdir()»

• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога: chroot()».

• Текущее значение относительного приоритета.

• ID процесса и ID родительского процесса.

• ID группы процесса и контролирующий терминал; см. раздел 9.2.1 «Обзор управления работами».

• Маску сигналов процесса и любые ожидающие сигналы, а также любые не истекшие аварийные сигналы или таймеры (здесь не обсуждается; см. главу 10 «Сигналы»).

• Действительные ID пользователя и ID группы, а также дополнительный набор групп. Эффективные ID пользователя и группы (а следовательно, и сохраненные ID set-user и set-group) могут быть установлены с помощью битов setuid и setgid исполняемого файла. (Ничто из этого пока не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы».)

• Блокировки файлов сохраняются (также пока не обсуждалось; см. раздел 14.2 «Блокировка файлов»).

• Суммарное использованное время процессора для процесса и его потомков не меняется.

После exec размещение сигналов изменяется; дополнительные сведения см. в разделе 10.9 «Сигналы для fork() и exec()».

После exec все открытые файлы и каталоги остаются открытыми и доступными для использования. Вот как программы наследуют стандартные ввод, вывод и ошибку: они на месте, когда программа запускается.

В большинстве случаев при исполнении fork и exec для отдельной программы не нужно ничего наследовать, кроме дескрипторов файлов 0, 1 и 2. В этом случае можно вручную закрыть все другие открытые файлы в порожденном процессе после выполнения fork и до выполнения exec. В качестве альтернативы можно пометить дескриптор файла для автоматического закрытия системой при исполнении exec; эта последняя возможность обсуждается далее в главе (см раздел 9.4.3.1 «Флаг close-on-exec».)

 

9.1.5. Завершение процесса

 

Завершение процесса включает два шага: окончание процесса с передачей системе статуса завершения и восстановление информации родительским процессом.

 

9.1.5.1. Определение статуса завершения процесса

Статус завершения (exit status) (известный также под другими именами значения завершения (exit value), кода возврата (return code) и возвращаемого значения (return value)) представляет собой 8-битовое значение, которое родитель может использовать при завершении порожденного процесса (на языке Unix, «когда порожденный кончается (dies)»). По соглашению статус завершения 0 означает, что программа отработала без проблем. Любое ненулевое значение указывает на какую-нибудь разновидность ошибки; программа определяет используемые числа и их значения, если они есть. (Например, grep использует 0 для указания, что образец был встречен по крайней мере один раз, 1 означает, что образец вообще не встретился, а 2 означает, что возникла ошибка.) Этот статус завершения доступен на уровне оболочки (для оболочек в стиле оболочки Борна) через специальную переменную $?.

Стандарт С определяет две константы, которые следует использовать для полной переносимости на не-POSIX системы:

EXIT_SUCCESS

Программа завершилась без проблем. Для обозначения успеха может также использоваться ноль.

EXIT_FAILURE

В программе была какая-нибудь проблема.

На практике использование лишь этих значений довольно ограничивает. Вместо этого следует выбрать небольшой набор кодов возврата, документировать их значения и использовать. (Например, 1 для ошибок опций командной строки и аргументов, 2 для ошибок ввода/вывода, 3 для ошибок данных и т.д.) Для удобочитаемости стоит использовать константы #define или значения enum. Слишком большой список ошибок делает их использование обременительным; в большинстве случаев вызывающая программа (или пользователь) интересуется лишь нулевым или ненулевым значением.

Когда достаточно двоичного разделения успех/неудача, педантичный программист использует EXIT_SUCCESS и EXIT_FAILURE. Наш собственный стиль более естественный, используя с return и exit() явные константы 0 или 1. Это настолько обычно, что рано заучивается и быстро становится второй натурой. Однако для своих проектов вы сами должны принять решение.

ЗАМЕЧАНИЕ . Для родительского процесса доступны лишь восемь наименее значимых битов значения. Поэтому следует использовать значения в диапазоне 0–255. Как мы вскоре увидим, у чисел 126 и 127 есть традиционные значения (помимо простого «неуспешно»), которых ваши программы должны придерживаться.

Поскольку имеют значение лишь восемь наименее значимых битов, вы никогда не должны использовать отрицательные статусы завершения. Когда из небольших отрицательных чисел выделяются восемь последних битов, они превращаются в большие положительные значения! (Например. -1 становится 255, а -5 становится 251.) Мы видели книги по программированию на С, в которых это понималось неправильно — не дайте сбить себя с толку

 

9.1.5.2. Возвращение из

main()

Программа может естественно завершиться одним из двух способов: посредством использования одной из описанных далее функций или возвратившись из main(). (Третий, более радикальный способ описан далее в разделе 12.4 «Совершение самоубийства: abort()».) В последнем случае следует использовать явное возвращаемое значение вместо выпадения в конце функции:

/* Правильно */                  /* Неправильно */

int main(int argc, char **argv)  int main(int argc, char **argv)

{                                {

 /* здесь код */                  /* здесь код */

 return 0;                        /* ?? Что возвращает main()? */

}                                }

Стандарт С 1999 г. указывает, что при выпадении в конце, поведение функции main() должно быть таким, как если бы она возвращала 0. (Это верно также для С++; однако, стандарт С 1989 г. намеренно оставляет этот случай неопределенным.) Во всех случаях плохо полагаться на это поведение; однажды вы можете программировать для системы со скудной поддержкой С времени исполнения, или для внедренной системы, или где-то еще, где это будет по-другому. (В общем, выпадение в конце любой функции, не являющейся void — плохая мысль, которая может вести лишь к ошибочному коду.)

Возвращенное из main() значение автоматически передается обратно системе, от которой родительский процесс может его впоследствии получить. Мы опишем, как это делается, в разделе 9.1.6.1 «Использование функций POSIX: wait() и waitpid()».

ЗАМЕЧАНИЕ . На системах GNU/Linux управляемая компилятором команда c99 запускает компилятор с соответствующими опциями, так что возвращаемое значение при выпадении из конца функции равно 0. Простой gcc этого не делает.

 

9.1.5.3. Функции завершения

Другим способом естественного завершения программы является вызов функций завершения. Стандарт С определяет следующие функции:

#include /* ISO С */

void exit(int status);

void _Exit(int status);

int atexit(void (*function)(void));

Эти функции работают следующим образом:

void exit(int status)

Эта функция завершает программу, status передается системе для использования родителем. Перед завершением программы exit() вызывает все функции, зарегистрированные с помощью atexit(), сбрасывает на диск и закрывает все открытые потоки FILE* и удаляет все временные файлы, созданные tmpfile() (см. раздел 12.3.2 «Создание и открытие временных файлов»). Когда процесс завершается, ядро закрывает любые оставшиеся открытыми файлы (которые были открыты посредством open(), creat() или через наследование дескрипторов), освобождает его адресное пространство и освобождает любые другие ресурсы, которые он мог использовать. exit() никогда не возвращается.

void _Exit(int status)

Эта функция в сущности идентична функции POSIX _exit(); мы на короткое время отложим ее обсуждение,

int atexit(void (*function)(void))

function является указателем на функцию обратного вызова, которая должна вызываться при завершении программы, exit() запускает функцию обратного вызова перед закрытием файлов и завершением. Идея в том, что приложение может предоставить одну или более функций очистки, которые должны быть запущены перед окончательным завершением работы. Предоставление функции называется ее регистрацией. (Функции обратного вызова для nftw() обсуждались в разделе 8.4.3.2 «Функция обратного вызова nftw()»; здесь та же идея, хотя atexit() вызывает каждую зарегистрированную функцию лишь однажды.)

atexit() возвращает 0 при успехе или -1 при неудаче и соответствующим образом устанавливает errno.

Следующая программа не делает полезной работы, но демонстрирует, как работает atexit():

/* ch09-atexit.c --- демонстрация atexit().

   Проверка ошибок для краткости опущена. */

/*

 * Функции обратного вызова здесь просто отвечают на вызов.

 * В настоящем приложении они делали бы больше. */

void callback1(void) { printf("callback1 called\n"); }

void callback2(void) { printf("callback2 called\n"); }

void callback3(void) { printf("callback3 called\n"); }

/* main --- регистрация функций и завершение */

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

 printf("registering callback1\n"); atexit(callback1);

 printf("registering callback2\n"); atexit(callback2);

 printf("registering callback3\n"); atexit(callback3);

 printf("exiting now\n");

 exit(0);

}

Вот что происходит при запуске:

$ ch09-atexit

registering callback1 /* Запуск главной программы */

registering callback2

registering callback3

exiting now

callback3 called /* Функции обратного вызова запускаются в обратном

                    порядке */

callback2 called

callback1 called

Как показывает пример, функции, зарегистрированные с помощью atexit(), запускаются в порядке, обратном порядку их регистрации: последние первыми. (Это обозначается также LIFO — last-in-first-out — вошедший последним выходит первым).

POSIX определяет функцию _exit(). В отличие от exit(), которая вызывает функции обратного вызова и выполняет -очистку, _exit() является «сразу заканчивающейся» функцией:

#include /* POSIX */

void _exit(int status);

Системе передается status, как и для exit(), но процесс завершается немедленно. Ядро все еще делает обычную очистку: все открытые файлы закрываются, использованная адресным пространством память освобождается, любые другие ресурсы, использованные процессом, также освобождаются.

На практике функция _Exit() ISO С идентична _exit(). Стандарт С говорит, что от реализации функции зависит, вызывает ли _Exit() зарегистрированные atexit() функции и закрывает ли открытые файлы. Для систем GLIBC это не так, и функция ведет себя подобно _exit().

Время использовать _exit() наступает, когда exec в порожденном процессе завершается неудачей. В этом случае вам не нужно использовать обычный exit(), поскольку это сбрасывает на диск данные буферов, хранящиеся в потоках FILE*. Когда позже родительский процесс сбрасывает на диск свои копии буферов, данные буфера оказываются записанными дважды; это очевидно нехорошо.

Например, предположим, что вы хотите запустить команду оболочки и хотите сами выполнить fork и exec. Такой код выглядел бы следующим образом:

char *shellcommand = "...";

pid_t child;

if ((child = fork()) == 0) { /* порожденный процесс */

 execl("/bin/sh", "sh", "-c", shellcommand, NULL);

 _exit(errno == ENOENT ? 127 : 126);

}

/* родитель продолжает */

Проверка значения errno и завершающего значения следуют соглашениям, используемым оболочкой POSIX. Если запрошенная программа не существует (ENOENT — нет для неё элемента в каталоге), завершающее значение равно 127. В противном случае, файл существует, но exec не могла быть выполнена по какой-то другой причине, поэтому статус завершения равен 126. Хорошая мысль следовать этим соглашениям также и в ваших программах. Вкратце, чтобы хорошо использовать exit() и atexit(), следует делать следующее:

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

• Решить, имеет ли смысл наличие функций обратного вызова для использования с atexit(). Если имеет, зарегистрировать их в main() в соответствующий момент; например, после анализа опций и инициализации всех структур данных, которые функция обратного вызова должна очищать. Помните, что функции должны вызываться в порядке LIFO (последняя вызывается первой).

• Использовать exit() для выхода из программы во всех местах, когда что-то идет не так и когда выход является правильным действием. Используйте коды ошибок, которые определили.

• Исключением является main(), для которой можно использовать при желании return. Наш собственный стиль заключается обычно в использовании exit() при наличии проблем и 'return 0' в конце main(), если все прошло хорошо.

• Использовать _exit() или _Exit() в порожденном процессе, если exec() завершается неудачей.

 

9.1.6. Использование статуса завершения порожденного процесса

 

Когда процесс заканчивается, нормальным ходом событий для ядра является освобождение всех его ресурсов. Ядро сохраняет статус завершения законченного процесса, также, как сведения о ресурсах, которые он использовал в своей работе, a PID продолжает считаться используемым. Такой завершившийся процесс называется зомби.

Родительский процесс, будь то первоначальный родитель или init, может получить статус завершения порожденного процесса. Или, посредством использования функций BDS, которые не стандартизованы POSIX, можно получить статус завершения вместе со сведениями об использовании ресурсов. Использование статуса осуществляется ожиданием окончания процесса: это известно также как пожинание (reaping) процесса.

Между механизмами, которые ожидают завершения потомков, и сигнальными механизмами, которые мы еще не обсуждали, есть значительное взаимодействие. Что из них описать вначале представляет собой нечто вроде проблемы курицы и яйца; мы решили сначала поговорить сначала о механизмах ожидания порожденного процесса, а глава 10 «Сигналы» дает полный рассказ о сигналах.

Пока достаточно понять, что сигнал является способом уведомления процесса о том, что произошло некоторое событие. Процессы могут генерировать сигналы, которые посылаются самим себе, или сигналы могут посылаться извне другими процессами или пользователем за терминалом. Например, CTRL-C посылает сигнал «прерывания», a CTRL-Z посылает сигнал управления работой «стоп».

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

 

9.1.6.1. Использование функций POSIX:

wait()

и

waitpid()

Первоначальным системным вызовом V7 был wait(). Более новым вызовом POSIX, основанным на возможностях BSD, является waitpid(). Объявления функций следующие:

#include /* POSIX */

#include

pid_t wait(int *status);

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

wait() ждет завершения любого порожденного процесса; сведения о том, как он завершился, возвращаются в *status. (Вскоре мы обсудим, как интерпретировать *status.) Возвращаемое значение является PID завершившегося процесса или -1, если возникла ошибка.

Если порожденных процессов нет, wait() возвращает -1 с errno, установленным в ECHILD (отсутствует порожденный процесс). В противном случае, функция ждет завершения первого порожденного процесса или поступления сигнала.

Функция waitpid() дает возможность ждать завершения определенного порожденного процесса. Она предоставляет значительную гибкость и является предпочтительной для использования функцией. Она также возвращает PID закончившегося процесса или -1 при возникновении ошибки. Аргументы следующие:

pid_t pid

Значение указывает, завершения какого порожденного процесса ждать как по-настоящему pid, так и по группе процесса. Смысл значения pid следующий:

pid < -1 Ждать завершения любого порожденного процесса с ID группы процесса, равной абсолютному значению pid.

pid = -1 Ждать завершения любого порожденного процесса. Таким способом работает wait().

pid = 0  Ждать завершения любого порожденного процесса с ID группы процесса, равной ID группе родительского процесса.

pid > 0  Ждать завершения конкретного процесса с PID, равным pid.

int *status

То же, что и для wait(). определяет различные макросы, которые интерпретируют значение в *status, которые мы вскоре опишем

int options

Этот параметр должен быть равен либо 0, либо побитовым ИЛИ одного или более из следующих флагов:

 WNOHANG

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

 WUNTRACED

 Вернуть сведения о порожденном процессе, который остановился, но еще не завершился. (Например, для управления работой.)

 WCONTINUED

 (XSI.) Вернуть сведения о порожденном процессе, который продолжился, если его статус не сообщался с момента изменения. Это также для управления работой. Этот флаг является расширением XSI и не доступен под GNU/Linux.

С заполненным значением *status работают несколько макросов, определяющие, что случилось. Они имеют тенденцию образовывать пары: один макрос для определения, что что-то случилось, и если этот макрос истинен, еще один макрос позволяет получить подробности. Макросы следующие:

WIFEXITED(status)

Этот макрос не равен нулю (true), если процесс завершился (в противоположность изменению состояния).

WEXITSTATUS(status)

Этот макрос дает статус завершения; он равен восьми наименее значимым битам значения, переданного exit() или возвращенного из main(). Этот макрос следует использовать лишь если WIFEXIDED(status) равен true.

WIFSIGNALED(status)

Этот макрос не равен нулю, если процесс подвергся действию завершающего сигнала death-by-signal.

WTERMSIG(status)

Этот макрос предоставляет номер сигнала, который завершил процесс. Этот макрос следует использовать, лишь когда WIFSIGNALED(status) равен true.

WIFSTOPPED(status)

Этот макрос не равен нулю, если процесс был остановлен.

WSTOPSIG(status)

Этот макрос предоставляет номер сигнала, который остановил процесс. (Процесс остановить могут несколько сигналов.) Этот макрос следует использовать лишь когда WIFSTOPPED(status) равен true. Сигналы управления работами обсуждаются в разделе 10.8.2 «Сигналы управления работой».

WIFCONTINUED(status)

(XSI.) Этот макрос не равен нулю, если процесс был продолжен. Соответствующего макроса WCONTSIG() нет, поскольку лишь один сигнал может вызвать продолжение процесса.

Обратите внимание, что этот макрос является расширением XSI и в частности, он недоступен в GNU/Linux. Следовательно, если вы хотите его использовать, заключите код внутри '#ifdef WIFCONTINUED ... #endif'.

WCOREDUMP(status)

(Общий.) Этот макрос не равен нулю, если процесс создал снимок. Снимок процесса (core dump) является образом запущенного процесса в памяти, созданном при завершении процесса. Он предназначен для использования впоследствии при отладке. Системы Unix называют файл core, тогда как системы GNU/Linux используют corе. pid , где pid является ID завершившегося процесса. Определенные сигналы завершают процесс и автоматически создают снимок процесса.

Обратите внимание, что этот макрос не стандартный. Системы GNU/Linux, Solaris и BSD его поддерживают, однако некоторые другие системы Unix нет. Поэтому и здесь, если нужно его использовать, заключите код внутрь '#ifdef WCOREDUMP ... #endif'.

Большинство программ не интересуются, почему завершился порожденный процесс; им просто нужно, что он завершился, возможно, отметив, было завершение успешным или нет. Программа GNU Coreutils install демонстрирует такое простое использование fork(), execlp() и wait(). Опция -s заставляет install запустить для устанавливаемого двоичного исполняемого файла программу strip. (strip удаляет из исполняемого файла отладочную и прочую информацию. Это может сохранить значительное пространство. На современных системах с многогигабайтными жесткими дисками при установке редко бывает необходимо использовать strip для исполняемых файлов.) Вот функция strip() из install.с:

513 /* Вырезать таблицу имен из файла PATH.

514    Мы могли бы сначала вытащить из файла магическое число

515    для определения, нужно ли вырезать, но заголовочные файлы и

516    магические числа варьируют от системы к системе так сильно, что

517    сделать его переносимым было бы очень трудно. Не стоит усилий. */

518

519 static void

520 strip (const char *path)

521 {

522  int status;

523  pid_t pid = fork();

524

525  switch (pid)

526  {

527  case -1:

528   error(EXIT_FAILURE, errno, _("fork system call failed"));

529   break;

530  case 0: /* Порожденный. */

531   execlp("strip", "strip", path, NULL);

532   error(EXIT_FAILURE, errno, _("cannot run strip"));

533   break;

534  default: /* Родитель. */

535   /* Родительский процесс. */

536   while (pid != wait(&status)) /* Ждать завершения потомка. */

537    /* Ничего не делать. */ ;

538   if (status)

539    error(EXIT_FAILURE, 0, _("strip failed"));

540   break;

541  }

542 }

Строка 523 вызывает fork(). Затем оператор switch предпринимает нужное действие для возвращения ошибки (строки 527–529), порожденного процесса (строки 530–533) и родительского процесса (строки 534–539).

Стиль строк 536–537 типичен; они ожидают завершения нужного порожденного процесса. Возвращаемое значение wait() является PID этого потомка. Оно сравнивается с PID порожденного процесса, status проверяется лишь на предмет равенства нулю (строка 538), в случае ненулевого результата потомок завершился неудачно. (Тест, хотя и правильный, грубый, но простой. Более правильным был бы тест наподобие 'if (WIFEXITED(status) && WEXITSTATUS(status) != 0)'.)

Из описаний и кода, представленных до сих пор, может показаться, что родительские программы должны выбрать определенный момент, чтобы ожидать завершения любого порожденного процесса, возможно, с опросом в цикле (как делает install.c), ожидая всех потомков. В разделе 10.8.3 «Родительский надзор: три различные стратегии» мы увидим, что это необязательно. Скорее, сигналы предоставляют ряд механизмов для использования уведомлениями родителей о завершении порожденных процессов.

 

9.1.6.2. Использование функций BSD:

wait3()

и

wait4()

Системные вызовы BSD wait3() и wait4() полезны, если вы интересуетесь ресурсами, использованными порожденным процессом. Функции нестандартны (что означает, что они не являются частью POSIX), но широко доступны, в том числе на GNU/Linux. Объявления следующие:

#include /* Обычный */

#include

 /* Под GNU/Linux не нужно, но улучшает переносимость */

#include

#include

pid_t wait3(int *status, int options, struct rusage *rusage);

pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);

Переменная status та же, что и для wait() и waitpid(). Все описанные ранее макросы (WIFEXITED() и т.д.) могут использоваться и с ними.

Значение options также то же самое, что и для waitpid(): либо 0, либо побитовое ИЛИ с одним или обоими флагами WNOHANG и WUNTRACED.

wait3() ведет себя подобно wait(), получая сведения о первом доступном порожденном зомби, a wait4() подобна waitpid(), получая сведения об определенном процессе. Обе функции возвращают PID потомка, -1 при ошибке или 0, если нет доступных процессов и был использован флаг WNOHANG. Аргумент pid может принимать те же значения, что и аргумент pid для waitpid().

Ключевым отличием является указатель struct rusage. Если он не равен NULL, система заполняет ее сведениями о процессе. Эта структура описана в POSIX и в справочной странице getrusage(2):

struct rusage {

 struct timeval ru_utime; /* используемое время пользователя */

 struct timeval ru_stime; /* используемое системное время */

 long ru_maxrss;   /* максимальный размер резидентного набора */

 long ru_ixrss;    /* общий размер разделяемой памяти */

 long ru_idrss;    /* общий размер не разделяемых данных */

 long ru_isrss;    /* общий размер не разделяемого стека */

 long ru_minflt;   /* использование страниц */

 long ru_majflt;   /* ошибок страниц */

 long ru_nswap;    /* подкачек */

 long ru_inblock;  /* блочных операций ввода */

 long ru_oublock;  /* блочных операций вывода */

 long ru_msgsnd;   /* посланных сообщений */

 long ru_msgrcv;   /* полученных сообщений */

 long ru_nsignals; /* полученных сигналов */

 long ru_nvcsw;    /* добровольных переключений контекста */

 long ru_nivcsw;   /* принудительных переключений контекста */

};

Чисто BSD системы (4.3 Reno и более поздние) поддерживают все поля. В табл. 9.2 описаны доступность различных полей struct rusage для POSIX и Linux.

Таблица 9.2. Доступность полей struct rusage

Поле POSIX Linux Поле POSIX Linux
ru_utime ≥ 2.4 ru_nswap ≥2.4
ru_stime ≥2.4 ru_nvcsw ≥2.6
ru_minflt ≥2.4 ru_nivcsw ≥2.6
ru_majflt ≥2.4

Стандартом определены лишь поля, помеченные «POSIX». Хотя Linux определяет полную структуру, ядро 2.4 поддерживает лишь поля времени пользователя и системного времени. Ядро 2.6 поддерживает также поля, связанные с переключением контекста.

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

Эти два поля используют struct timeval, которая содержит значения времени с точностью до микросекунд. Дополнительные сведения по этой структуре см. в разделе 14.3.1 «Время в микросекундах: gettimeofday()».

В BSD 4.2 и 4.3 аргумент status функций wait() и wait3() был union wait. Он умещался в int и предоставлял доступ к тем же сведениям, которые выдают современные макросы WIFEXITED() и др., но через членов объединения. Не все члены были действительными во всех случаях. Эти члены и их использование описаны в табл. 9.3.

Таблица 9.3. union wait 4.2 и 4.3 BSD

Макрос POSIX Член объединения Использование Значение
WIFEXITED() w_termsig w.w_termsig == 0 True при нормальном завершении
WEXITSTATUS() w_retcode code = w.w_retcode Статус завершения, если не по сигналу
WIFSIGNALED() w_termsig w.w_temsig != 0 True, если завершен по сигналу
WTERMSIG() w_termsig sig = w.w_termsig Сигнал, вызвавший завершение
WIFSTOPPED() w_stopval w.w_stopval == WSTOPPED True, если остановлен
WSTOPSIG() w_stopsig sig = w.w_stopsig Сигнал, вызвавший остановку
WCOREDUMP() w_coredump w.w_coredump != 0 True, если потомок сделал снимок образа

POSIX не стандартизует union wait, a BSD 4.4 не документирует его, используя вместо этого макросы POSIX. GLIBC делает несколько бросков, чтобы заставить использующий его старый код продолжать работать. Мы опишем его здесь главным образом для того, чтобы вы увидев его — узнали; новый код должен использовать макросы, описанные в разделе 9.1.6.1 «Использование функций POSIX: wait() и waitpid()».

 

9.2. Группы процессов

 

Группа процесса является группой связанных процессов, которые в целях управления заданием (job) рассматриваются вместе. Процессы с одним и тем же ID группы процессов являются членами группы процессов, а процесс, PID которого равен ID группы процессов, является лидеров группы процессов. Новые процессы наследуют ID группы процессов своих родительских процессов.

Мы уже видели, что waitpid() позволяет вам ждать любой процесс в данной группе процессов. В разделе 10.6.7 «Отправка сигналов: kill() и killpg()» мы увидим также, что вы можете отправить сигнал всем процессам в определенной группе процессов. (Всегда применяется проверка прав доступа; вы не можете послать сигнал процессу, которым не владеете.)

 

9.2.1. Обзор управления заданиями

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

Устройство терминала (физическое или другое) с работающим на нем пользователем называется управляющим терминалом.

Сеанс (session) является коллекцией групп процессов, связанных с управляющим терминалом. На одном терминале имеется лишь один сеанс, с несколькими группами процессов в сеансе. Один процесс назначен лидером сеанса; обычно это оболочка, такая, как Bash, pdksh, zsh или ksh93, которая может осуществлять управление заданиями. Мы называем такую оболочку оболочкой, управляющей заданиями.

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

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

Группе процессов, ID которой совпадает с ID управляющего терминала, разрешено записывать в терминал и читать с него. Эта группа называется приоритетной (foreground) группой процессов. (Она получает также генерируемые клавиатурой сигналы.) Любые другие группы процессов в сеансе являются фоновыми (background) группами процессов и не могут читать или записывать в терминал; они получают специальные сигналы, которые их останавливают, если они пытаются это делать.

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

В былые времена пользователи часто использовали последовательные терминалы, соединенные с модемами, для подключения к централизованным Unix-системам на мини-компьютерах. Когда пользователь закрывал соединение (вешал трубку), линия последовательной передачи обнаруживала отсоединение, и ядро посылало сигнал «отсоединение» всем подключенным к терминалу процессам.

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

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

 

9.2.2. Идентификация группы процессов:

getpgrp()

и

getpgid()

Для совместимости с более старыми системами POSIX предоставляет множество способов получения сведений о группе процессов:

#include

pid_t getpgrp(void);      /* POSIX */

pid_t getpgid(pid_t pid); /* XSI */

Функция getpgrp() возвращает ID группы процессов текущего процесса. getpgid() является расширением XSI. Она возвращает ID группы процессов для данного pid группы процессов. pid, равный 0, означает «группа процессов текущего процесса». Таким образом, 'getpgid(0)' является тем же самым, что и 'getpgrp()'. При обычном программировании следует использовать getpgrp().

В BSD 4.2 и 4.3 также есть функция getpgrp(), но она действует как функция POSIX getpgid(), требуя аргумент pid. Поскольку современные системы поддерживают POSIX, в новом коде следует использовать версию POSIX. (Если вы думаете, что это сбивает с толку, вы правы. Несколько способов для получения одного и того же результата является обычным итогом проектирования комитетом, поскольку комитет считает, что он должен удовлетворить каждого.)

 

9.2.3. Установка группы процесса:

setpgid()

и

setpgrp()

Две функции устанавливают группу процесса:

#include

int setpgid(pid_t pid, pid_t pgid); /* POSIX */

int setpgrp(void);                  /* XSI */

Функция setpgrp() проста: она устанавливает ID группы процесса равной ID процесса. Это создает новую группу процессов в том же сеансе, а вызывающий функцию процесс становится лидером группы процессов.

Функция setpgid() предназначена для использования управления заданиями. Она позволяет одному процессу устанавливать группу процесса для другого. Процесс может изменить лишь свой собственный ID группы процессов или ID группы процессов порожденного процесса, лишь если этот порожденный процесс не выполнил еще exec. Управляющая заданиями оболочка делает этот вызов после fork как в родительском, так и в порожденном процессах. Для одного из них вызов завершается успехом, и ID группы процессов изменяется. (В противном случае нет способа гарантировать упорядочение, когда родитель может изменить ID группы процессов порожденного процесса до того, как последний выполнит exec. Если сначала успешно завершится вызов родителя, он может перейти на следующую задачу, такую, как обработка других заданий или управление терминалом.)

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

Имеется несколько значений для особых случаев как для pid, так и для pgid:

pid = 0 В данном случае setpgid() изменяет группу процессов вызывающего процесса на pgid. Это эквивалентно 'setpgid(getpid(), pgid)'.

pgid = 0 Это устанавливает ID группы процессов для данного процесса равным его PID. Таким образом, 'setpgid(pid, 0)' является тем же самым, что и 'setpgid(pid, pid)'. Это делает процесс с PID, равным pid, лидером группы процессов.

Во всех случаях лидеры сеанса являются особыми; их PID, ID группы процессов и ID сеанса идентичны, a ID группы процессов лидера не может быть изменена. (ID сеанса устанавливаются посредством setsid(), а получаются посредством getsid(). Это особые вызовы: см. справочные страницы setsid(2) и getsid(2)).

 

9.3. Базовое межпроцессное взаимодействие: каналы и очереди FIFO

 

Межпроцессное взаимодействие (Interprocess communication — IPC) соответствует своему названию: это способ взаимодействия для двух отдельных процессов. Самым старым способом IPC на системах Unix является канал (pipe): односторонняя линия связи. Данные, записанные в один конец канала, выходят из другого конца.

 

9.3.1. Каналы

 

Каналы проявляют себя как обычные дескрипторы файлов. Без особого разбирательства вы не можете сказать, представляет ли дескриптор файла сам файл или канал. Это особенность; программы, которые читают из стандартного ввода и записывают в стандартный вывод, не должны знать или заботиться о том, что они могут взаимодействовать с другим процессом. Если хотите знать, каноническим способом проверки этого является попытка выполнить с дескриптором 'lseek(fd, 0L, SEEK_CUR)'; этот вызов пытается отсчитать 0 байтов от текущего положения, т е. операция, которая ничего не делает. Эта операция завершается неудачей для каналов и не наносит никакого вреда другим файлам.

 

9.3.1.1. Создание каналов

Системный вызов pipe() создает канал:

#include /* POSIX */

int pipe(int filedes[2]);

Значение аргумента является адресом массива из двух элементов целого типа, pipe() возвращает 0 при успешном возвращении и -1, если была ошибка.

Если вызов был успешным, у процесса теперь есть два дополнительных открытых дескриптора файла. Значение filedes[0] является читаемым концом канала, a filedes [1] — записываемым концом. (Удобным мнемоническим способом запоминания является то, что читаемый конец использует индекс 0, аналогичный дескриптору стандартного ввода 0, а записываемый конец использует индекс 1, аналогичный дескриптору стандартного вывода 1.)

Как упоминалось, данные, записанные в записываемый конец, считываются из читаемого конца. После завершения работы с каналом оба конца закрываются с помощью вызова close(). Следующая простая программа, ch09-pipedemo.c, демонстрирует каналы путем создания канала, записи в него данных, а затем чтения этих данных из него:

1  /* ch09-pipedemo.c --- демонстрация ввода/вывода с каналом. */

2

3  #include

4  #include

5  #include

6

7  /* main --- создание канала, запись в него и чтение из него. */

8

9  int main(int argc, char **argv)

10 {

11  static const char mesg[] = "Don't Panic!"; /* известное сообщение */

12  char buf[BUFSIZ];

13  ssize_t rcount, wcount;

14  int pipefd[2];

15  size_t l;

16

17  if (pipe(pipefd) < 0) {

18   fprintf(stderr, "%s: pipe failed: %s\n", argv[0],

19    strerror(errno));

20   exit(1);

21  }

22

23  printf("Read end = fd %d, write end = fd %d\n",

24   pipefd[0], pipefd[1]);

25

26  l = strlen(mesg);

27  if ((wcount = write(pipefd[1], mesg, 1)) != 1) {

28   fprintf(stderr, "%s: write failed: %s\n", argv[0],

29    strerror(errno));

30   exit(1);

31  }

32

33  if ((rcount = read(pipefd[0], buf, BUFSIZ)) != wcount) {

34   fprintf(stderr, "%s: read failed: %s\n", argv[0],

35    strerror(errno));

36   exit(1);

37  }

38

39  buf[rcount] = '\0';

40

41  printf("Read <%s> from pipe\n", buf);

42  (void)close(pipefd[0]);

43  (void)close(pipefd[1]);

44

45  return 0;

46 }

Строки 11–15 объявляют локальные переменные; наибольший интерес представляет mesg, который представляет текст, проходящий по каналу.

Строки 17–21 создают канал с проверкой ошибок; строки 23–24 выводят значения новых дескрипторов файлов (просто для подтверждения, что они не равны 0, 1 или 2)

В строке 26 получают длину сообщения для использования с write(). Строки 27–31 записывают сообщение в канал, снова с проверкой ошибок.

Строки 33–37 считывают содержимое канала, опять с проверкой ошибок. Строка 39 предоставляет завершающий нулевой байт, так что прочитанные данные могут использоваться в качестве обычной строки. Строка 41 выводит данные, а строки 42–43 закрывают оба конца канала. Вот что происходит при запуске программы:

$ ch09-pipedemo

Read end = fd 3, write end = fd 4

Read from pipe

Эта программа не делает ничего полезного, но она демонстрирует основы. Обратите внимание, что нет вызовов open() или creat() и что программа не использует три своих унаследованных дескриптора. Тем не менее, write() и read() завершаются успешно, показывая, что дескрипторы файлов действительны и что данные, поступающие в канал, действительно выходят из него. Конечно, будь сообщение слишком большим, наша программа не работала бы. Это происходит из-за того, что размер (памяти) каналов ограничен, факт, который мы обсудим в следующем разделе.

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

 

9.3.1.2. Буферирование каналов

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

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

Подобным же образом, если канал пустой, потребитель блокируется в read() до тех пор, пока в канале не появятся данные для чтения. (Блокирующее поведение можно отключить; это обсуждается в разделе 9.4.3.4 «Неблокирующий ввод/вывод для каналов и очередей FIFO».)

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

Напротив, если потребитель закрывает читаемый конец, write() на записываемом конце завершается неудачей. В частности, ядро посылает производителю сигнал «нарушенный канал», действием по умолчанию для которого является завершение процесса.

Нашей любимой аналогией для каналов является то, как муж и жена вместе моют и сушат тарелки. Один супруг моет тарелки, помещая чистые, но влажные тарелки в сушилку на раковине. Другой супруг вынимает тарелки из сушилки и вытирает их. Моющий тарелки является производителем, сушилка является каналом, а вытирающий является потребителем.

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

Рис. 9.3. Синхронизация процессов канала

 

9.3.2. Очереди FIFO

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

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

Для решения этой проблемы System III предложила идею о FIFO. FIFO, или именованный канал, является файлом в файловой системе, который действует подобно каналу. Другими словами, один процесс открывает FIFO для записи, тогда как другой открывает его для чтения. Затем данные, записанные; в FIFO, читаются читателем. Данные буферируются ядром, а не хранятся на диске.

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

Функция mkfifo() создает файлы FIFO:

#include /* POSIX */

#include

int mkfifo(const char *pathname, mode_t mode);

Аргумент pathname является именем создаваемого FIFO, a mode является данными ему правами доступа, аналогичными второму аргументу функции creat() или третьему аргументу функции open() (см. раздел 4.6 «Создание файлов»). Файлы FIFO удаляются, как любые другие, с помощью remove() или unlink() (см. раздел 5.1.5.1 «Удаление открытых файлов»).

Справочная страница GNU/Linux mkfifo(3) указывает, что FIFO должен быть открыт как для чтения, так и для записи в одно и то же время, до того, как может быть осуществлен ввод/вывод: «Открытие FIFO для чтения обычно блокирует до тех пор, пока какой-нибудь другой процесс не откроет тот же FIFO для записи, и наоборот». После открытия файла FIFO он действует подобно обычному каналу; т.е. это просто еще один дескриптор файла.

Команда mkfifo доставляет этот системный вызов на командный уровень. Это упрощает показ файла FIFO в действии:

$ mkfifo afifo /* Создание файла FIFO */

$ ls -l afifo

 /* Показать тип и права доступа, обратите внимание на 'p' впереди */

prw-r--r-- 1 arnold devel 0 Oct 23 15:49 afifo

$ cat < afifo & /* Запустить читателя в фоновом режиме */

[1] 22100

$ echo It was a Blustery Day > afifo /* Послать данные в FIFO */

$ It was a Blustery Day /* Приглашение оболочки, cat выводит данные */

 /* Нажмите ENTER, чтобы увидеть статус завершения задания */

[1]+ Done cat

 

9.4. Управление дескрипторами файлов

 

На данный момент части загадки почти полностью составлены, fork() и exec() создают процессы и запускают в них программы, pipe() создает канал, который может использоваться для IPC. Чего до сих пор не хватает, так это способа помещения дескрипторов канала на место стандартных ввода и вывода для производителя и потребителя канала.

Системные вызовы dup() и dup2(), совместно с close() дают вам возможность поместить (скопировать) открытый дескриптор файла на другой номер. Системный вызов fcntl() дает вам возможность то же самое и управлять несколькими важными атрибутами открытых файлов.

 

9.4.1. Дублирование открытых файлов:

dup()

и

dup2()

Два системных вызова создают копию открытого дескриптора файла:

#include /* POSIX */

int dup(int oldfd);

int dup2(int oldfd, int newfd);

Функции следующие:

int dup(int oldfd)

Возвращает наименьшее значение неиспользуемого дескриптора файла; это копия oldfd. dup() возвращает неотрицательное целое в случае успеха и -1 при неудаче.

int dup2(int oldfd, int newfd)

Делает newfd копией oldfd; если newfd открыт, он сначала закрывается, как при использовании close(). dup2() возвращает новый дескриптор или -1, если была проблема. Помните рис. 9.1, в котором два процесса разделяли общие указатели на один и тот же элемент файла в таблице файлов ядра? dup() и dup2() создают ту же ситуацию внутри одного процесса. См. рис. 9.4.

Рис. 9.4. Разделение дескриптора файла как результат 'dup2(1, 3)'

На этом рисунке процесс выполнил 'dup2(1, 3)', чтобы сделать дескриптор файла 3-й копией стандартного вывода, дескриптора файла 1. Точно как описано ранее, эти два дескриптора разделяют общее смещение открытого файла.

В разделе 4.4.2 «Открытие и закрытие файлов» мы упомянули, что open() (и creat()) всегда возвращают наименьшее целое значение неиспользуемого дескриптора для открываемого файла. Этому правилу следуют почти все системные вызовы, которые возвращают новые дескрипторы файлов, а не только open() и creat(). (dup2() является исключением, поскольку он предусматривает способ получения конкретного нового дескриптора файла, даже если он не является наименьшим неиспользуемым дескриптором.)

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

1. Создать канал с помощью pipe(). Это должно быть сделано сначала, чтобы два порожденных процесса могли унаследовать дескрипторы открытых файлов.

2. Создать то, что мы называем «левым потомком». Это процесс, стандартный вывод которого идет в канал. В данном процессе сделать следующее:

 a. Использовать 'close(pipefd[0])', поскольку читаемый конец канала в левом потомке не нужен.

 b. Использовать 'close(1)', чтобы закрыть первоначальный стандартный вывод.

 c. Использовать 'dup(pipefd[1])' для копирования записываемого конца канала в дескриптор файла 1.

 d. Использовать 'close(pipefd[1])', поскольку нам не нужны две копии открытого дескриптора.

 e. Выполнить exec для запускаемой программы.

3. Создать то, что мы называем «правым потомком». Это процесс, стандартный ввод которого поступает из канала. Шаги для этого потомка являются зеркальным отражением шагов для левого потомка:

 a. Использовать 'close(pipefd[1])', поскольку записываемый конец канала в правом потомке не нужен.

 b. Использовать 'close(0)', чтобы закрыть первоначальный стандартный ввод.

 c. Использовать 'dup(pipefd[0])' для копирования читаемого конца канала в дескриптор файла 0.

 d. Использовать 'close(pipefd[0])', поскольку нам не нужны две копии открытого дескриптора.

 e. Выполнить exec для запускаемой программы.

4. В родителе закрыть оба конца канала — 'close(pipefd[0]); close(pipefd[1])'.

5. Наконец, использовать в родителе wait() для ожидания завершения обоих порожденных процессов.

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

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

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

Следующая программа, ch09-pipeline.c, создает эквивалент следующего конвейера оболочки:

$ echo hi there | sed s/hi/hello/g

hello there

Вот программа:

1  /* ch09-pipeline.c --- ответвляет два процесса в их собственный конвейер.

2     Для краткости проверка ошибок сведена к минимуму. */

3

4  #include

5  #include

6  #include

7  #include

8  #include

9

10 int pipefd[2];

11

12 extern void left_child(void), right_child(void);

13

14 /* main --- порождение процессов и ожидание их завершения */

15

16 int main(int argc, char **argv)

17 {

18  pid_t left_pid, right_pid;

19  pid_t ret;

20  int status;

21

22  if (pipe(pipefd) < 0) { /* создать канал в самом начале */

23   perror("pipe");

24   exit(1);

25  }

26

27  if ((left_pid = fork()) < 0) { /* порождение левого потомка */

28   perror("fork");

29   exit(1);

30  } else if (left_pid == 0)

31  left_child();

32

33  if ((right_pid = fork()) < 0) { /* порождение правого потомка */

34   perror("fork");

35   exit(1);

36  } else if (right_pid == 0)

37  right_child();

38

39  close(pipefd[0])); /* закрыть родительские копии канала */

40  close(pipefd[1]);

41

42  while ((ret = wait(&status)) > 0) { /* wait for children */

43   if (ret == left_pid)

44    printf("left child terminated, status: %x\n", status);

45   else if (ret == right_pid)

46    printf("right child terminated, status: %x\n", status);

47   else

48    printf("yow! unknown child %d terminated, status %x\n",

49     ret, status);

50  }

51

52  return 0;

53 }

Строки 22–25 создают канал. Это должно быть сделано в самом начале.

Строки 27–31 создают левого потомка, а строки 33–37 создают правого потомка. В обоих случаях родитель продолжает линейное исполнение ветви main() до тех пор, пока порожденный процесс не вызовет соответствующую функцию для манипулирования дескрипторами файла и осуществления exec.

Строки 39–40 закрывают родительскую копию канала.

Строки 42–50 в цикле ожидают потомков, пока wait() не вернет ошибку.

55 /* left_child --- осуществляет работу левого потомка */

56

57 void left_child(void)

58 {

59  static char *left_argv[] = { "echo", "hi", "there", NULL };

60

61  close(pipefd[0]);

62  close(1);

63  dup(pipefd[1]);

64  close(pipefd[1]);

65

66  execvp("echo", left_argv);

67  _exit(errno == ENOENT ? 127 : 126);

68 }

69

70 /* right_child --- осуществляет работу правого потомка */

71

72 void right_child(void)

73 {

74  static char *right_argv[] = { "sed", "s/hi/hello/g", NULL };

75

76  close(pipefd[1]);

77  close(0);

78  dup(pipefd[0]);

79  close(pipefd[0]));

80

81  execvp("sed", right_argv);

82  _exit(errno == ENOENT ? 127 : 126);

83 }

Строки 57–68 являются кодом для левого потомка. Процедура следует приведенным выше шагам, закрывая ненужный конец канала, закрывая первоначальный стандартный вывод, помещая с помощью dup() записываемый конец канала на номер 1 и закрывая затем первоначальный записываемый конец. В этот момент строка 66 вызывает execvp(), и если она завершается неудачей, строка 67 вызывает _exit(). (Помните, что строка 67 никогда не выполняется, если execvp() завершается удачно.)

Строки 72–83 делают подобные же шаги для правого потомка. Вот что происходит при запуске:

$ ch09-pipeline /* Запуск программы */

left child terminated, status: 0 /* Левый потомок завершается до вывода (!) */

hello there /* Вывод от правого потомка */

right child terminated, status: 0

$ ch09-pipeline /* Повторный запуск программы */

hello there /* Вывод от правого потомка и ... */

right child terminated, status: 0 /* Правый потомок завершается до левого */

left child terminated, status: 0

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

Весь процесс показан на рис. 9.5.

Рис. 9.5. Создание конвейера родителем

На рис. 9.5 (а) изображена ситуация после создания родителем канала (строки 22–25) и двух порожденных процессов (строки 27–37).

На рис. 9.5 (b) показана ситуация после закрытия родителем канала (строки 39–40) и начала ожидания порожденных процессов (строки 42–50). Каждый порожденный процесс поместил канал на место стандартного вывода (левый потомок, строки 61–63) и стандартного ввода (строки 76–78).

Наконец, рис. 9.5 (с) изображает ситуацию после закрытия потомками первоначального канала (строки 64 и 79) и вызова execvp() (строки 66 и 81).

 

9.4.2. Создание нелинейных конвейеров:

/dev/fd/XX

Многие современные системы Unix, включая GNU/Linux, поддерживают в каталоге /dev/fd специальные файлы. Эти файлы представляют дескрипторы открытых файлов с именами /dev/fd/0, /dev/fd/1 и т.д. Передача такого имени функции open() возвращает новый дескриптор файла, что в сущности является тем же самым, что и вызов dup() для данного номера дескриптора.

Эти специальные файлы находят свое применение на уровне оболочки: Bash, ksh88 (некоторые версии) и ksh93 предоставляют возможность замещения процесса (process substitution), что позволяет создавать нелинейные конвейеры. На уровне оболочки для входного конвейера используется запись '<(...)', а для выходного конвейера запись '>(...)'. Например, предположим, вам нужно применить команду diff к выводу двух команд. Обычно вам пришлось бы использовать временные файлы:

command1 > /tmp/out.$$.1

command2 > /tmp/out.$$.2

diff /tmp/out.$$.1 /tmp/out.$$.2

rm /tmp/out.$$.1 /tmp/out.$$.2

С замещением процессов это выглядит следующим образом:

diff <(command1) <(command2)

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

$ diff <(pwd) <(/bin/pwd)

1c1

< /home/arnold/work/prenhall/progex

---

> /d/home/arnold/work/prenhall/progex

Незамысловатая команда pwd является встроенной в оболочку: она выводит текущий логический путь, который управляется оболочкой с помощью команды cd. Программа /bin/pwd осуществляет обход физической файловой системы для вывода имени пути.

Как выглядит замещение процессов? Оболочка создает вспомогательные команды ('pwd' и '/bin/pwd'). Выход каждой из них подсоединяется к каналу, причем читаемый конец открыт в дескрипторе нового файла для главного процесса ('diff'). Затем оболочка передает главному процессу имена файлов в /dev/fd в качестве аргументов командной строки. Мы можем увидеть это, включив в оболочке трассировку исполнения.

$ set -х /* Включить трассировку исполнения */

$ diff <(pwd) <(/bin/pwd) /* Запустить команду */

+ diff /dev/fd/63 /dev/fd/62 /* Трассировка оболочки: главная,

 программа, обратите внимание на аргументы */

++ pwd /* Трассировка оболочки: вспомогательные программы */

++ /bin/pwd

1c1 /* Вывод diff */

< /home/arnold/work/prenhall/progex

---

> /d/home/arnold/work/prenhall/progex

Это показано на рис. 9.6.

Рис. 9.6. Замещение процесса

Если на вашей системе есть /dev/fd, вы также можете использовать преимущества этой возможности. Однако, будьте осторожны и задокументируйте то, что вы делаете. Манипуляции с дескриптором файла на уровне С значительно менее прозрачны, чем соответствующие записи оболочки!

 

9.4.3. Управление атрибутами файла:

fcntl()

 

Системный вызов fcntl() («управление файлом») предоставляет контроль над различными атрибутами либо самого дескриптора файла, либо лежащего в его основе открытого файла. Справочная страница GNU/Linux fcntl(2) описывает это таким способом:

#include /* POSIX */

#include

int fcntl (int fd, int cmd);

int fcntl(int fd, int cmd, long arg);

int fcntl(int fd, int cmd, struct flock *lock);

Другими словами, функция принимает по крайней мере два аргумента; в зависимости от второго аргумента, она может принимать и третий аргумент.

Последняя форма, в которой третий аргумент является указателем на struct flock, предназначена для блокировки файла. Блокировка файлов сама по себе представляет большую тему; мы отложим обсуждение до раздела 14.2 «Блокировка файлов».

 

9.4.3.1. Флаг close-on-exec

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

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

int j;

for (j = getdtablesize(); j >= 3; j--) /* закрыть все, кроме 0, 1, 2 */

 (void)close(j);

Решением является флаг close-on-exec (закрытие при исполнении exec). Он является атрибутом самого дескриптора файла, а не лежащего в его основе открытого файла. Когда этот флаг установлен, система автоматически закрывает файл, когда процесс осуществляет exec. Установив этот флаг сразу после открытия файла, вам не нужно беспокоиться о том, что какой-нибудь порожденный процесс случайно его унаследует. (Оболочка автоматически устанавливает этот флаг для всех дескрипторов файлов, которые она открывает, начиная с номера 3 и выше.)

Аргумент cmd имеет два значения, относящиеся к флагу close-on-exec:

F_GETFD

Получает флаги дескриптора файла. Возвращаемое значение является значением всех установленных флагов дескриптора или -1 при ошибке.

F_SETFD

Устанавливает флаги дескриптора файла в содержащееся в arg (третий аргумент) значение. Возвращаемое значение равно 0 при успехе или -1 при ошибке.

В настоящий момент определен лишь один «флаг дескриптора файла»: FD_CLOEXEC. Эта именованная константа является нововведением POSIX, а большая часть кода использует просто 1 или 0:

if (fcntl(fd, F_SETFD, 1) < 0) ...

 /* установить close-on-exec, обработать ошибки */

if (fcntl(fd, F_GETFD) == 1) ...

 /* бит close-on-exec уже установлен */

Однако, определение POSIX допускает дальнейшее расширение, поэтому правильный способ написания такого кода больше соответствует этим строкам:

int fd;

long fd_flags;

if ((fd_flags = fcntl(fd, F_GETFD)) < 0) /* Получить флаги */

 /* обработать ошибки */

fd_flags |= FD_CLOEXEC; /* Add close-on-exec flag */

if (fcntl(fd, F_SETFD, fd_flags) < 0) /* Установить флаги */

 /* обработать ошибки */

ЗАМЕЧАНИЕ . Флаг close-on-exec является собственностью дескриптора, а не лежащего в его основе файла. Поэтому новый дескриптор, возвращенный функциями dup() или dup2() (или fcntl() с F_DUPD , которую мы намереваемся посмотреть), не наследует установки флага close-on-exec первоначального дескриптора. Если вам нужно установить его также и для нового дескриптора файла, вы должны не забыть сделать это сами. Такое поведение имеет смысл: если вы просто вызвали dup() , копируя один конец канала в 0 или 1, вы не захотите, чтобы система закрыла его вместо вас, как только процесс осуществит exec!

История борьбы close-on-exec от gawk

В языке awk операторы ввода/вывода используют обозначение перенаправления, сходное с обозначением для оболочки. Это включает односторонние каналы к и от подпроцесса:

print "something brilliant" > "/some/file" /* Вывод в файл */

getline my_record < "/some/other/file" /* Ввод из файла */

print "more words of wisdom" | "a_reader process" /* Вывод в подпроцесс */

"a_write_process" | getline some_input /* Ввод из подпроцесса */

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

Теперь на современных системах часть стартового кода библиотеки С времени исполнения (который запускается до вызова main() ) нуждается для управления использованием разделяемых библиотек во временно открытых файлах. Это означает, что для новой программы после исполнения exec должны быть по крайней мере один или два неиспользуемых дескриптора файла, иначе программа просто не будет работать

Однажды один пользователь сообщил, что когда в программе было максимальное количество открытых файлов, ни один процесс, для которого она пыталась использовать для конвейера fork и exec , не мог успешно начаться!

Вы, возможно, можете догадаться, что произошло. Порожденная оболочка унаследовала дескрипторы открытых файлов, которые gawk сама использовала для своих перенаправлений. Мы модифицировали gawk так, чтобы установить флаг close-on-exec для всех перенаправлений файлов и каналов, что и решило проблему.

 

9.4.3.2. Дублирование дескриптора файла

Когда аргумент cmd функции fcntl() равен F_DUPFD, ее поведение похоже, но не идентично поведению dup2(). В этом случае arg является дескриптором файла, представляющим наименьшее приемлемое значение для нового дескриптора файла:

int new_fd = fcntl(old_fd, F_DUPFD, 7);

 /* Возвращаемое значение между 7 и максимумом или неудача */

int new_fd = dup2(old_fd, 7);

 /* Возвращаемое значение 7 или неудача */

Вы можете имитировать поведение dup(), которая возвращает наименьший свободный дескриптор файла, использовав 'fcntl(old_fd, F_DUPED, 0)'.

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

Использовать ли в собственном коде fcntl() с F_DUPED или dup() или dup2(), в значительной степени является делом вкуса. Все три функции API являются частью POSIX и широко поддерживаются. У нас легкое пристрастие к dup() и dup2(), поскольку они более специфичны в своих действиях, поэтому являются самодокументирующимися. Но поскольку все они довольно просты, эта аргументация может вас не убедить.

 

9.4.3.3. Работа с флагами статуса файла и режимами доступа

В разделе 4.6.3 «Возвращаясь к open()» мы предоставили полный список флагов O_xx, которые принимает open(). POSIX разбивает их по функциям, классифицируя в соответствии с табл. 9.4.

Таблица 9.4. Флаги O_xx для open(), creat() и fcntl()

Категория Функции Флаги
Доступ к файлу open() , fcntl() O_RDONLY , O_RDWR , O_WRONLY
Создание файла open() O_CREAT , O_EXCL , O_NOCTTY , O_TRUNC
Статус файла open() , fcntl() O_APPEND , O_DSYNC , O_NONBLOCK , O_RSYNC , O_SYNC

Помимо первоначальной установки различных флагов с помощью open(), вы можете использовать fcntl() для получения текущих установок, а также их изменения. Это осуществляется с помощью значений cmd F_GETFL и F_SETFL соответственно. Например, вы можете использовать эти команды для изменения установки неблокирующего флага, O_NONBLOCK, подобным образом:

int fd_flags;

if ((fd_flags = fcntl(fd, F_GETFL)) < 0)

 /* обработать ошибку */

if ((fd_flags & O_NONBLOCK) != 0) { /* Установлен неблокирующий флаг */

 fd_flags &= ~O_NONBLOCK; /* Сбросить его */

 if (fcntl(fd, F_SETFL, fd_flags) != 0) /* Дать ядру новое значение */

  /* обработать ошибку */

}

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

fd_flags = fcntl(fd, F_GETFL);

switch (fd_flags & O_ACCESS) {

case O_RDONLY:

 /* ...действия только для чтения... */

 break;

case O_WRONLY:

 /* ...действия только для записи... */

 break;

case O_RDWR:

 /* ...действия для чтения и записи... */

 break;

}

POSIX требует, чтобы O_RDONLY, O_RDWR и O_WRONLY были побитово различными, таким образом, гарантируется, что код, подобный только что показанному, будет работать и является простым способом определения того, как был открыт произвольный дескриптор файла.

Используя F_SETFL вы можете также изменить эти режимы, хотя по-прежнему применяется проверка прав доступа. Согласно справочной странице GNU/Linux fcnlt(2) флаг O_APPEND не может быть сброшен, если он использовался при открытии файла.

 

9.4.3.4. Неблокирующий ввод/вывод для каналов и FIFO

Ранее для описания способа работы каналов мы использовали сравнение с двумя людьми, моющими и вытирающими тарелки с использованием сушилки; когда сушилка заполняется, останавливается моющий, а когда она пустеет, останавливается вытирающий. Это блокирующее поведение: производитель или потребитель блокируются в вызове write() или read(), ожидая либо освобождения канала, либо появления в нем данных.

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

На языке Unix/POSIX эта концепция обозначается термином неблокирующий ввод/вывод, т.е. запрошенный ввод/вывод либо завершается, либо возвращает значение ошибки, указывающее на отсутствие данных (для читающего) или отсутствие места (для записывающего). Неблокирующий ввод/вывод применяется к каналам и FIFO, а не к обычным файлам на диске. Он может применяться также и к определенным устройствам, таким как терминалы, и к сетевым соединениям, обе эти темы выходят за рамки данной книги.

С функцией open() может использоваться флаг O_NONBLOCK для указания неблокирующего ввода/вывода, он может быть установлен и сброшен с помощью fcntl(). Для open() и read() неблокирующий ввод/вывод прост.

Открытие FIFO с установленным или сброшенным O_NONBLOCK демонстрирует следующее поведение:

open("/fifо/file", O_RDONLY, mode)

Блокируется до открытия FIFO для записи.

open("/fifo/file", O_RDONLY | O_NONBLOCK, mode)

Открывает файл, возвращаясь немедленно.

open("/fifo/file", O_WRONLY, mode)

Блокирует до открытия FIFO для чтения.

open("/fifo/file", O_WRONLY | O_NONBLOCK, mode)

Если FIFO был открыт для чтения, открывает FIFO и немедленно возвращается. В противном случае возвращает ошибку (возвращаемое значение -1 и errno установлен в ENXIO).

Как описано для обычных каналов, вызов read() для FIFO, который больше не открыт для чтения, возвращает конец файла (возвращаемое значение 0). Флаг O_NONBLOCK в данном случае неуместен. Для пустого канала или FIFO (все еще открытых для записи, но не содержащих данных) все становится интереснее:

read(fd, buf, count) и сброшенный O_NONBLOCK

Функция read() блокируется до тех пор, пока в канал или FIFO не поступят данные.

read(fd, buf, count) и установленный O_NONBLOCK

Функция read() немедленно возвращает -1 с установленным в errno EAGAIN.

В заключение, поведение write() более сложно. Для обсуждения этого нам нужно сначала представить концепцию атомарной записи. Атомарная запись — это такая запись, при которой все данные записываются целиком, не чередуясь с данными от других записей. POSIX определяет в константу PIPE_BUF. Запись в канал или FIFO данных размером менее или равным PIPE_BUF байтов либо успешно завершается, либо блокируется в соответствии с подробностями, которые мы скоро приведем. Минимальным значением для PIPE_BUF является _POSIX_PIPE_BUF, что равняется 512. Само значение PIPE_BUF может быть больше; современные системы GLIBC определяют ее размер в 4096, но в любом случае следует использовать эту именованную константу и не ожидать, что PIPE_BUF будет иметь то же значение на разных системах.

Во всех случаях для каналов и FIFO write() добавляет данные в конец канала. Это происходит от того факта, что у каналов нет файловых смещений: в них нельзя осуществлять поиск.

Также во всех случаях, как упоминалось, записи размером вплоть до PIPE_BUF являются атомарными: данные не перемежаются с данными от других записей. Данные записи размером более PIPE_BUF байтов могут перемежаться с данными других записей в произвольных границах. Это последнее означает, что вы не можете ожидать, что каждая порция размером PIPE_BUF большого набора данных будет записана атомарно. Установка O_NONBLOCK не влияет на это правило.

Как и в случае с read(), когда O_NONBLOCK не установлен, write() блокируется до тех пор, пока все данные не будут записаны.

Наиболее все усложняется, когда установлен O_NONBLOCK. Канал или FIFO ведут себя следующим образом:

размер ≥ nbytes размер < abytes
nbytes ≤ PIPE_BUF write() успешна write() возвращает (-1)/EAGAIN
размер > 0 размер = 0
nbytes > PIPE_BUF write() записывает, что может write() возвращает (-1)/EAGAIN

Для файлов, не являющихся каналами и FIFO и к которым может быть применен O_NONBLOCK, поведение следующее:

размер > 0 write() записывает, что может

размер = 0 write() возвращает -1/EAGAIN

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

• Всегда можно отличить конец файла: read() возвращает 0 байтов.

• Если нет доступных для чтения данных, read() либо завершается успешно, либо возвращает указание «нет данных для чтения»: EAGAIN, что означает «попытайтесь снова позже».

• Если для записи нет места, write() либо блокируется до успешного завершения (O_NONBLOCK сброшен), либо завершается неудачей с ошибкой «в данный момент нет места для записи»: EAGAIN.

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

Подводя итог, если вы собираетесь использовать неблокирующий ввод/вывод, любой код, который использует write(), должен быть способен обработать укороченную запись, когда успешно записан меньший объем данных, чем было затребовано. Устойчивый код в любом случае должен быть написан таким способом: даже в случае обычного файла диск может оказаться заполненным и write() сможет записать лишь часть данных.

Более того, вы должны быть готовы обработать EAGAIN, понимая, что в этом случае неудача write() не обязательно означает фатальную ошибку. То же верно для кода, использующего для чтения неблокирующий ввод/вывод: признайте, что и здесь EAGAIN не является фатальным. (Однако, может стоит подсчитывать число таких отказов, оставив попытки, когда их слишком много.)

Неблокирующий ввод/вывод действительно усложняет вашу жизнь, в этом нет никакого сомнения. Но для многих приложений он является необходимостью, позволяющей выполнить задание. Снова рассмотрите спулер печати. Демон спулера не может позволить себе находиться в блокирующем read() для файла FIFO, которому представлены входящие задания. Он должен иметь также возможность отслеживать запущенные задания и, возможно, периодически проверять состояние печатающих устройств (например, убедиться, что не заело бумагу).

 

9.4.3.5. Сводка fcntl()

Сводка для системного вызова fcntl() приведена в табл. 9.5.

Таблица 9.5. Сводка fcntl()

Значение cmd Значение arg Возвращает
F_DUPFD Наименьший новый дескриптор Дублирует аргумент fd
F_GETFD Получает флаги дескриптора файла (close-on-exec)
F_SETFD Новое значение флага Устанавливает флаги дескриптора файла (close-on-exec)
F_GETFL Получает флаги основного файла
F_SETFL Новое значение флага Устанавливает флаги основного файла

Флаги создания, статуса и прав доступа файла копируются, когда дескриптор файла дублируется. Флаг close-on-exec не копируется.

 

9.5. Пример: двусторонние каналы в

gawk

Двусторонний канал соединяет два процесса двунаправленным образом. Обычно, по крайней мере для одного из процессов, на канал с другим процессом настраиваются как стандартный ввод, так и стандартный вывод. Оболочка Корна (ksh) ввела двусторонние каналы на уровне языка, обозначив термином сопроцесса (coprocess):

команды и аргументы движка базы данных |& /* Запустить сопроцесс в фоновом режиме */

print -p "команда базы данных" /* Записать в сопроцесс */

read -p db_response /* Прочесть из сопроцесса */

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

Рис. 9.7. Сопроцессы оболочки Корна

В обычном awk каналы к или от подпроцесса являются односторонними: нет способа послать данные в программу и прочесть посланные от нее в ответ данные — нужно использовать временный файл. GNU awk (gawk) заимствует обозначение '|&' от ksh для расширения языка awk:

print " команда " |& " движок базы данных " /* Запустить сопроцесс, записать в него */

" движок базы данных " |& getline db_response /* Прочесть из сопроцесса */

gawk использует запись '|&' также для сокетов TCP/IP и порталов BSD, которые не рассматриваются в данной книге. Следующий код из io.c в дистрибутиве gawk 3.1.3 является частью функции two_way_open(), которая устанавливает простой сопроцесс: она создает два канала, порождает новый процесс и осуществляет все манипуляции с дескриптором файла. Мы опустили ряд не относящихся к делу частей кода (эта функция занимает больше места, чем следовало бы):

1561 static int

1562 two_way_open(const char *str, struct redirect *rp)

1563 {

      ...

1827 /* случай 3: двусторонний канал с порожденным процессом */

1828 {

1829  int ptoc[2], сtop[2];

1830  int pid;

1831  int save_errno;

1835

1836  if (pipe(ptoc) < 0)

1837   return FALSE; /* установлен errno, диагностика от вызывающего */

1838

1839  if (pipe(ctop) < 0) {

1840   save_errno = errno;

1841   close(ptoc[0]);

1842   close(ptoc[1]);

1843   errno = save_errno;

1844   return FALSE;

1845  }

Первым шагом является создание двух каналов, ptoc является каналом «от родителя к потомку», а ctop — «от потомка к родителю». Во время чтения держите в уме, что индекс 0 является читаемым концом, а 1 — записываемым.

Строки 1836–1837 создают первый канал, ptoc. Строки 1839–1845 создают второй канал, закрывая при неудачном создании и первый. Это важно. Небрежность в закрытии открытых, но не используемых каналов ведет к утечкам дескрипторов файлов. Как и память, дескрипторы файлов являются конечным ресурсом, и когда они иссякают, то теряются. То же верно и для открытых файлов: убедитесь, что ваш обрабатывающий ошибки код всегда закрывает все открытые файлы и каналы, которые не нужны, когда происходит ошибка.

save_errno сохраняет значения errno, установленные pipe(), на тот редкий случай, когда close() может завершиться неудачей (строка 1840). Затем errno восстанавливается в строке 1843.

1906 if ((pid = fork()) < 0) {

1907  save_errno = errno;

1908  close(ptoc[0]); close(ptoc[1]);

1909  close(ctop[0]); close(ctop[1]);

1910  errno = save_errno;

1911  return FALSE;

1912 }

Строки 1906–1912 порождают процесс, на этот раз закрывая оба канала, если fork() потерпит неудачу. Здесь также первоначальное значение errno сохраняется и восстанавливается для последующего использования при диагностике.

1914 if (pid == 0) { /* порожденный процесс */

1915  if (close(1) == -1)

1916   fatal(_("close of stdout in child failed (%s)"),

1917    strerror(errno));

1918  if (dup(ctop[1]) != 1)

1919   fatal(_{"moving pipe to stdout in child failed (dup: %s)"), strerror(errno));

1920  if (close(0) == -1)

1921   fatal(_("close of stdin in child failed (%s)"),

1922    strerror(errno));

1923  if (dup(ptoc[0]) != 0)

1924   fatal(_("moving pipe to stdin in child failed (dup: %s)"), strerror(errno));

1925  if (close(ptoc[0]) == -1 || close(ptoc[1]) == -1

1926   || close(ctop[0]) == -1 || close(ctop[1]) == -1)

1927   fatal(_("close of pipe failed (%s)"), strerror(errno));

1928  /* stderr HE дублируется в stdout потомка */

1929  execl("/bin/sh", "sh", "-c", str, NULL);

1930  _exit(errno == ENOENT ? 127 : 126);

1931 }

Строки 1914–1931 обрабатывают код потомка, с соответствующей проверкой ошибок и сообщениями на каждом шагу. Строка 1915 закрывает стандартный вывод. Строка 1918 копирует записываемый конец канала от потомка к родителю на 1. Строка 1920 закрывает стандартный ввод, а строка 1923 копирует читаемый конец канала от родителя к потомку на 0. Если это все работает, стандартные ввод и вывод теперь на месте и подключены к родителю.

Строки 1925–1926 закрывают все четыре первоначальные дескрипторы файлов каналов, поскольку они больше не нужны. Строка 1928 напоминает нам, что стандартная ошибка остается на месте. Это лучшее решение, поскольку пользователь увидит ошибки от сопроцесса. Программа awk, которая должна перехватить стандартную ошибку, может использовать в команде обозначение '2>&1' для перенаправления стандартной ошибки сопроцесса или записи в отдельный файл.

Наконец, строки 1929–1930 пытаются запустить для оболочки execl() и соответственно выходят, если это не удается.

1934 /* родитель */

1935 rp->pid = pid;

1936 rp->iop = iop_alloc(ctop[0], str, NULL);

1937 if (rp->iop == NULL) {

1938  (void)close(ctop[0]);

1939  (void)close(ctop[1]);

1940  (void)close(ptoc[0]);

1941  (void)close(ptoc[1]);

1942  (void)kill(pid, SIGKILL); /* overkill? (pardon pun) */

1943

1944  return FALSE;

1945 }

Первым шагом родителя является настройка входного конца от сопроцесса. Указатель rp указывает на struct redirect, которая содержит поле для сохранения PID порожденного процесса, FILE* для вывода и указатель IOBUF* с именем iop. IOBUF является внутренней структурой данных gawk для осуществления ввода. Она, в свою очередь, хранит копию нижележащего дескриптора файла.

Строка 1935 сохраняет значение ID процесса. Строка 1936 выделяет память для новой IOBUF для данных дескриптора файла и командной строки. Третий аргумент здесь равен NULL: он позволяет при необходимости использовать предварительно выделенный IOBUF.

Если выделение памяти потерпело неудачу, строки 1937–1942 производят очистку, закрывая каналы и посылая сигнал «kill» порожденным процессам, чтобы заставить их завершить работу. (Функция kill() описана в разделе 10.6.7 «Отправка сигналов kill() и killpg()».)

1946 rp->fp = fdopen(ptoc[1], "w");

1947 if (rp->fp == NULL) {

1948  iop_close(rp->iop);

1949  rp->iop = NULL;

1950  (void)close(ctop[0]);

1951  (void)close(ctop[1]);

1952  (void)close(ptoc[0]);

1953  (void)close(ptoc[1]);

1954  (void)kill(pid, SIGKILL); /* избыточно? (пардон, каламбур) */

1955

1956  return FALSE;

1957 }

Строки 1946–1957 аналогичны. Они устанавливают вывод родителя на потомка, сохраняя дескриптор файла для записывающего конца канала от родителя к потомку в FILE*, используя функцию fdopen(). Если это завершается неудачей, строки 1947–1957 предпринимают те же действия, что и ранее: закрывают все дескрипторы каналов и посылают сигнал порожденным процессам.

С этого момента записываемый конец канала от родителя к потомку и читаемый конец канала от потомка к родителю хранятся в более крупных структурах: FILE* и IOBUF соответственно. Они автоматически закрываются обычными процедурами, которые закрывают эти структуры. Однако, остаются две задачи:

1960   os_close_on_exec(ctop[0], str, "pipe", "from");

1961   os_close_on_exec(ptoc[1], str, "pipe", "from");

1962

1963   (void)close(ptoc[0]);

1964   (void)close(ctop[1]);

1966

1967   return TRUE;

1968  }

      ...

1977 }

Строки 1960–1961 устанавливают флаг close-on-exec для двух дескрипторов, которые остались открытыми. os_close_on_exec() является простой функцией-оболочкой, которая выполняет эту работу на Unix- и POSIX-совместимых системах, но ничего не делает на системах, в которых нет флага close-on-exec. Это скрывает проблему переносимости в одном месте и позволяет избежать в коде множества запутывающих #ifdef здесь и в других местах io.c.

Наконец, строки 1963–1964 закрывают концы каналов, которые не нужны родителю, а строка 1967 возвращает TRUE для обозначения успеха.

 

9.6. Рекомендуемая литература

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

1. Advanced Programming in the UNIX Environment, 2nd edition, by W. Richard Stevens and Stephen Rago. Addison-Wesley, Reading Massachusetts, USA, 2004. ISBN: 0-201-43307-9.

Эта книга и полна, и основательна, охватывая элементарное и продвинутое программирование под Unix. Она превосходно освещает группы процессов, сеансы, управление заданиями и сигналы

2. The Design and Implementation of the 4.4 BSD Operating System, by Marshall Kirk McKusick, Keith Bostic, Michael J. Karels, and John S. Quarterman. Addison-Wesley, Reading, Massachusetts, USA, 1996. ISBN: 0-201-54979-4.

Эта книга дает хороший обзор того же материала, включая обсуждение структур данных ядра, которое можно найти в разделе 4.8 этой книги.

 

9.7. Резюме

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

• Унаследованные разделяемые дескрипторы файлов делают возможным многое из высокоуровневой семантики Unix и элегантные управляющие структуры оболочки. Это одна из наиболее фундаментальных частей оригинального дизайна Unix. Из-за разделения дескрипторов файл на самом деле не закрывается до тех пор, пока не будет закрыт последний открытый дескриптор файла. Это в особенности касается каналов, но затрагивает также освобождение дисковых блоков для удаленных, но все еще открытых файлов.

• Вызовы getpid() и getppid() возвращают ID текущего и родительского процессов соответственно. Родителем процесса, первоначальный родитель которого завершается, становится специальный процесс init с PID 1. Таким образом, PPID может меняться, и приложения должны быть готовы к этому.

• Системный вызов nice() дает возможность настраивать приоритет вашего процесса. Чем приятнее вы по отношению к другим процессам, тем меньше ваш относительный приоритет, и наоборот. Лишь суперпользователь может иметь больший приоритет по сравнению с другими процессами. На современных системах, особенно однопользовательских, нет действительных причин для изменения знамения относительного приоритета.

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

• Значение argv[0] для новой программы обычно происходит от имени исполняемого файла, но это лишь соглашение. Как и в случае с fork(), значительный, но не идентичный набор атрибутов наследуется через exec. Другие атрибуты сбрасываются для использования подходящих значений по умолчанию.

• Функция atexit() регистрирует функции обратного вызова для вызова в порядке LIFO при завершении программы. Функции exit(), _exit() и _Exit() все завершают программу, передавая статус завершения обратно родителю, exit() очищает открытые потоки FILE* и запускает функции, зарегистрированные с помощью atexit(). Две другие функции завершаются немедленно и должны использоваться, лишь когда exec в порожденном процессе завершилась неудачей. Возвращение из main() подобно вызову exit() с данным возвращаемым значением. В C99 и C++ выпадение из main() в конце функции дает тот же результат, что и 'exit(0)', но является плохой практикой.

• wait() и waitpid() являются функциями POSIX для получения статуса завершения порожденного процесса. Различные макросы позволяют определить, завершился ли порожденный процесс нормально, и в таком случае определить статус его завершения, или же порожденный процесс претерпел сигнал завершения, и в этом случае определить совершивший этот проступок сигнал. Со специальными опциями waitpid() предоставляет также сведения о потомках, которые не завершились, но изменили состояние.

• Системы GNU/Linux и большинство Unix-систем поддерживают также функции BSD wait3() и wait4(). GNU/Linux поддерживает также выходящий из употребления union wait. Функции BSD предоставляют struct rusage, давая доступ к сведениям об использовании времени процессора, что может быть удобным. Хотя если waitpid() будет достаточной, то это наиболее переносимый способ выполнения.

• Группы процессов являются частью более крупного механизма управления заданиями, который включает сигналы, сеансы и манипулирование состоянием терминала, getpgrp() возвращает ID группы процессов текущего процесса, a getpgid() возвращает PGID определенного процесса. Сходным образом, setpgrp() устанавливает PGID текущего процесса равным его PID, делая его лидером группы процессов; setpgid() дает возможность родительскому процессу установить PGID порожденного, который еще не выполнил exec.

• Каналы и FIFO предоставляют односторонний коммуникационный канал между двумя процессами. Каналы должны быть установлены общим предком, тогда как FIFO могут использоваться любыми двумя процессами. Каналы создаются с помощью pipe(), а файлы FIFO создаются с помощью mkfifo(). Каналы и FIFO буферируют свои данные, останавливая производителя или потребителя, когда канал заполняется или пустеет.

• dup() и dup2() создают копии дескрипторов открытых файлов. В сочетании с close() они дают возможность поместить дескрипторы файлов на место стандартного ввода и вывода для каналов. Чтобы каналы работали правильно, все копии неиспользуемых концов каналов до исполнения программой назначения exec должны быть закрыты. Для создания нелинейных каналов может быть использован /dev/fd, что демонстрируется возможностью замещения процессов оболочками Bash и Korn.

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

 • Дублирования дескриптора файла, имитирования dup() и почти имитирования dup2().

 • Получения и установки флага close-on-exec. Флаг close-on-exec является в настоящее время единственным атрибутом дескриптора файла, но он важен. Он не копируется в результате действия dup(), но должен явным образом устанавливаться для дескрипторов файлов, которые не должны оставаться открытыми после выполнения exec. На практике, это должно быть сделано для большинства дескрипторов файла.

 • Получение и установка флагов, управляющих нижележащим файлом. Из них O_NONBLOCK является, пожалуй, наиболее полезным, по крайней мере, для FIFO и каналов. Это определенно самый сложный флаг.

 

Упражнения

1. Напишите программу, которая выводит как можно больше сведений о текущем процессе: PID, PPID, открытые файлы, текущий каталог, значение относительного приоритета и т.д. Как вы можете сказать, какие файлы открыты? Если несколько дескрипторов файлов ссылаются на один и тот же файл, укажите это. (Опять-таки, как вы можете это узнать?)

2. Как вы думаете, atexit() хранит указатели на функции обратного вызова? Реализуйте atexit(), держа в уме принцип GNU «никаких произвольных ограничений». Набросайте схему (псевдокод) для exit(). Каких сведений (внутренностей библиотеки ) вам не хватает, чтобы написать exit()?

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

$ grep ARG_MAX /usr/include/*.h /usr/include/*/*.h /* Командная строка */

bash: /bin/grep: Argument list too long /* Сообщение оболочки об ошибке */

$ find /usr/include -name '*.h' | xargs grep ARG_MAX /* find b xargs работают */

/usr/include/sys/param.h:#define NCARGS ARG_MAX

...

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

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

4. Компоновка значения status, заполняемого функциями wait() и waitpid(), стандартом POSIX не определяется. Хотя и историческое, это 16-разрядное значение, которое выглядит, как показано на рис. 9.8.

Рис. 9.8. Компоновка значения status функции wait()

 • Ненулевое значение в битах 0–7 указывает на завершение по сигналу.

 • Все единичные биты в поле сигнала указывает, что порожденный процесс остановлен. В этом случае биты 9-15 содержат номер сигнала.

 • Единичное значение бита 8 указывает завершение со снимком процесса.

 • Если биты 0–7 равны нулю, процесс завершился нормально. В этом случае биты 9–15 являются статусом завершения.

Напишите с данными сведениями макросы POSIX WIFEXITED() и др.

5. Помня, что dup2() сначала закрывает запрошенный дескриптор файла, реализуйте dup2(), используя close() и fcntl(). Как вы обработаете случай, когда fcntl() возвращает значение меньше запрошенного?

6. Есть ли на вашей системе каталог /dev/fd? Если есть, как он реализован?

7. Напишите новую версию ch09-pipeline.c, которая порождает лишь один процесс. После порождения родитель должен поменять дескрипторы своих файлов и сам выполнить exec для одной из новых программ.

8. (Трудное) Как вы можете узнать, вызывал ли ваш процесс когда-нибудь chroot()? Напишите программу, которая проверяет это и выводит сообщение с ответом да или нет. Можно ли обмануть вашу программу? Если да, как?

9. Есть ли на вашей системе каталог /proc? Если да, доступ к какой информации о процессе он обеспечивает?

 

Глава 10

Сигналы

 

Данная глава освещает все подробности сигналов, важную, но сложную часть GNU/Linux API.

 

10.1. Введение

Сигнал является указанием, что случилось какое-то событие, например, попытка сослаться на адрес памяти, который не является частью адресного пространства вашей программы, или когда пользователь нажимает CTRL-C для выхода из программы (называется генерированием прерывания).

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

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

В отличие от большинства глав в данной книге, наше представление здесь историческое, связанное с освещением развития API, включая API, которые никогда не следует использовать в новом коде. Мы делаем это, потому что это упрощает изложение, делая понятным, почему функция POSIX API sigaction() поддерживает все те возможности, которые поддерживает.

 

10.2. Действия сигналов

Каждый сигнал (вскоре мы представим полный список) имеет связанное с ним действие по умолчанию. POSIX обозначает это как диспозицию (disposition) сигнала. Это то действие, которое ядро осуществляет для процесса, когда поступает определенный сигнал. Действие по умолчанию варьирует:

Завершение

Процесс завершается.

Игнорирование

Сигнал игнорируется. Программа никогда не узнает, что что-то случилось.

Снимок образа процесса

Процесс завершается, и ядро создает файл core (в текущем каталоге процесса), содержащий образ работавшей на момент поступления сигнала программы. Снимок процесса может впоследствии использоваться с отладчиком для исследования состояния программы (см. главу 15 «Отладка»).

По умолчанию системы GNU/Linux создают файлы с именем core. pid , где pid является ID завершаемого процесса. (Это можно изменить; см. sysctl(8).) Такое именование позволяет хранить в одном и том же каталоге несколько файлов core, за счет использования большего дискового пространства. Традиционные системы Unix называют файл core, и это ваше дело сохранить какие-нибудь файлы core для последующего изучения, если есть шанс создания других таких же файлов в том же каталоге.

Остановка

Процесс останавливается. Впоследствии он может быть возобновлен. (Если вы использовали управление заданиями оболочки с помощью CTRL-Z, fg и bg, вы понимаете остановку процесса.)

 

10.3. Стандартные сигналы С:

signal()

и

raise()

 

Стандарт ISO С определяет первоначальный API управления сигналами V7 и новый API для посылки сигналов. Вы должны использовать их для программ, которым придется работать на не-POSIX системах, или в случаях, когда предоставляемые ISO С API возможности являются достаточными.

 

10.3.1. Функция

signal()

Действие сигнала изменяется с помощью функции signal(). Вы можете изменить действие на «игнорировать сигнал», «восстановить для сигнала действие системы по умолчанию» или «вызвать при появлении сигнала мою функцию с номером сигнала в качестве параметра».

Функция, которую вы предоставляете для распоряжения сигналом, называется обработчиком сигнала (или просто обработчиком), а установка ее в соответствующем месте осуществляет перехват (catch) сигнала.

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

#include /* ISO С */

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

Это объявление для функции signal() почти невозможно прочесть. Поэтому справочная страница GNU/Linux signal(2) определяет ее таким способом:

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

Теперь это более вразумительно. Тип sighandler_t является указателем на функцию с возвращаемым типом void, которая принимает один целый аргумент. Это целое является номером поступающего сигнала.

Функция signal() принимает номер сигнала в качестве своего первого параметра, а указатель функции (новый обработчик) в качестве своего второго аргумента. Если последний не является указателем функции, он может быть лишь SIG_DEF, что означает «восстановить действие по умолчанию», либо SIG_IGN, что означает «игнорировать сигнал».

signal() изменяет действие для signum и возвращает предыдущее действие. (Это дает вам возможность восстановить при желании предыдущее действие.) Возвращаемое значение может равняться также SIG_ERR, что указывает на произошедшую ошибку. (Некоторые сигналы невозможно перехватить или игнорировать; предоставление для них обработчика сигнала или неверный signum создают эту ошибку.) В табл. 10.1 перечислены сигналы, доступные под GNU/Linux, их числовые значения, действия по умолчанию для каждого, формальный стандарт или современная операционная система, которые их определяют, и смысл каждого.

Таблица 10.1. Сигналы GNU/Linux

Имя Значение По умолчанию Источник Смысл
SIGHUP 1 Term POSIX Отсоединение
SIGINT 2 Term ISO C Прерывание
SIGQUIT 3 Core POSIX Выход
SIGILL 4 Core ISO C Недействительная инструкция
SIGTRAP 5 Core POSIX Трассировочная ловушка
SIGABRT 6 Core ISO C Прекращение
SIGIOT 6 Core BSD Ловушка IOT
SIGBUS 7 Core BSD Ошибка шины
SIGFPE 8 Core ISO C Исключение с плавающей точкой
SIGKILL 9 Term POSIX Завершение, неблокируемый
SIGUSR1 10 Term POSIX Сигнал 1 пользователя
SIGSEGV 11 Core ISO C Нарушение сегмента
SIGUSR2 12 Term POSIX Сигнал 2 пользователя
SIGPIPE 13 Term POSIX Нарушенный канал
SIGALRM 14 Term POSIX Аварийные часы
SIGTERM 15 Term ISO C Завершение
SIGSTKFLT 16 Term Linux Ошибка стека в процессоре (не используется)
SIGCHLD 17 Ignr POSIX Изменение статуса порожденного процесса
SIGCLD 17 Ignr System V То же, что и SIGCHLD (для совместимости)
SIGCONT 18 POSIX Продолжить при остановке
SIGSTOP 19 Stop POSIX Стоп, неблокируемый
SIGTSTP 20 Stop POSIX Стоп от клавиатуры
SIGTTIN 21 Slop POSIX Фоновое чтение от tty
SIGTTOU 22 Stop POSIX Фоновая запись в tty
SIGURG 23 Ignr BSD Срочный сигнал сокета
SIGXCPU 24 Core BSD Превышение предела процессора
SIGXFSZ 25 Core BSD Превышение предела размера файла
SIGVTALRM 26 Term BSD Виртуальные аварийные часы
SIGPROF 27 Term BSD Профилирующие аварийные часы
SIGWINCH 28 Ignr BSD Изменение размера окна
SIGIO 29 Term BSD Возможен ввод/вывод
SIGPOLL 29 Term System V Опрашиваемое событие, то же, что и SIGIO (для совместимости)
SIGPWR 30 Term System V Повторный запуск из-за сбоя питания
SIGSYS 31 Core POSIX Неверный системный вызов

Обозначения: Core: Завершить процесс и создать снимок образа процесса Ignr: Игнорировать сигнал Stop: Остановить процесс. Term: Завершить процесс.

Более старые версии оболочки Борна (/bin/sh) непосредственно связывали с номерами сигналов ловушки (traps), которые являются обработчиками сигналов на уровне оболочки. Таким образом, всесторонне образованному Unix-программисту нужно было знать не только имена сигналов для использования в коде С, но также и соответствующие номера сигналов! POSIX требует, чтобы команда trap понимала символические имена сигналов (без префикса 'SIG'), поэтому этого больше не требуется. Однако (главным образом для лучшего разбирательства), мы предоставили эти номера в интересах полноты из-за того, что однажды вам может понадобиться иметь дело со сценарием оболочки, созданным до POSIX, или с древним кодом на С, которые непосредственно используют номера сигналов.

ЗАМЕЧАНИЕ . Для некоторых более новых сигналов, от 16 и выше, соответствующие номера сигнала и их имена на различных платформах не обязательно совпадают! Проверьте заголовочные файлы и справочные страницы на своей системе. Табл. 10.1 верна для GNU/Linux

Некоторые системы определяют также и другие сигналы, такие, как SIGEMT, SIGLOST и SIGINFO. Справочная страница GNU/Linux signal(7) предоставляет полный список; если ваша программа должна обработать сигналы, не поддерживаемые GNU/Linux, это можно сделать с помощью #ifdef:

#ifdef SIGLOST

/* ...обработать здесь SIGLOST... */

#endif

За исключением SIGSTKFLT, сигналы, перечисленные в табл. 10.1, широкодоступны и не нуждаются в заключении в #ifdef.

Сигналы SIGKILL и SIGSTOP нельзя перехватить или игнорировать (или блокировать, как описано далее в главе). Они всегда выполняют действие по умолчанию, указанное в табл. 10.1.

Чтобы увидеть список поддерживаемых сигналов, вы можете использовать 'kill -l'. На одной из наших систем GNU/Linux:

$ kill -l

 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL

 5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE

 9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2

13) SIGPIPE     14) SIGALRM     15) SIGTERM     17) SIGCHLD

18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN

22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ

26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO

30) SIGPWR      31) SIGSYS      32) SIGRTMIN    33) SIGRTMIN+1

34) SIGRTMIN+2  35) SIGRTMIN+3  36) SIGRTMIN+4  37) SIGRTMIN+5

38) SIGRTMIN+6  39) SIGRTMIN+7  40) SIGRTMIN+8  41) SIGRTMIN+9

42) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+13

46) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-14

50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10

54) SIGRTMAX-9  55) SIGRTMAX-8  56) SIGRTMAX-7  57) SIGRTMAX-6

58) SIGRTMAX-5  59) SIGRTMAX-4  60) SIGRTMAX-3  61) SIGRTMAX-2

62) SIGRTMAX-1  63) SIGRTMAX

Сигналы SIGRT XXX являются сигналами реального времени, сложная тема, которую мы не будем рассматривать.

 

10.3.2. Программная отправка сигналов:

raise()

Помимо внешнего генерирования, сигнал может быть отправлен непосредственно самой программой с использованием стандартной функции С raise():

#include /* ISO С */

int raise(int sig);

Эта функция посылает сигнал sig вызывающему процессу. (Это действие имеет свое применение; вскоре мы увидим пример.)

Поскольку raise() определена стандартом С, для процесса это наиболее переносимый способ отправить себе сигнал. Есть другие способы, которые мы обсудим далее в главе.

 

10.4. Обработчики сигналов в действии

 

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

 

10.4.1. Традиционные системы

После помещения на место обработчика сигнала ваша программа развивается своим путем. Интересные вещи возникают лишь с появлением сигнала (например, пользователь нажал CTRL-C для прерывания вашей программы, или был сделан вызов raise()).

По получении сигнала ядро останавливает процесс, где бы он ни был. Затем оно имитирует вызов процедуры обработчика сигнала, передавая ему номер сигнала в качестве ее единственного аргумента. Ядро устраивает все таким образом, что нормальный возврат из функции обработчика сигнала (либо посредством return, либо в результате выпадения из конца функции) передает управление в ту точку программы, в которой она находилась в момент появления сигнала.

Что происходит после обработки сигнала, когда тот же самый сигнал появится в следующий раз снова? Остается ли обработчик на том же месте? Или же он сбрасывается, и для сигнала используется действие по умолчанию? Ответ, по историческим причинам, «зависит от». В частности, стандарт С оставляет это на усмотрение реализации.

На практике V7 и традиционные системы System V, такие, как Solaris, устанавливают для сигнала действие по умолчанию.

Давайте рассмотрим простой обработчик сигнала в действии под Solaris. Следующая программа, ch10-catchint.c, перехватывает SIGINT. Обычно вы генерируете этот сигнал, набирая на клавиатуре CTRL-C.

1  /* ch10-catchint.c - перехват SIGINT, по крайней мере, однажды. */

2

3  #include

4  #include

5  #include

6

7  /* handler --- простой обработчик сигнала. */

8

9  void handler(int signum)

10 {

11  char buf[200], *cp;

12  int offset;

13

14  /* Пройти через это испытание , чтобы избежать fprintf(). */

15  strcpy(buf, "handler: caught signal ");

16  cp = buf + strlen(buf); /* cp указывает на завершающий '\0' */

17  if (signum > 100) /* маловероятно */

18   offset = 3;

19  else if (signum > 10)

20   offset = 2;

21  else

22   offset = 1;

23  cp += offset;

24

25  *cp-- = '\0'; /* завершить строку */

26  while (signum >0) { /* work backwards, filling in digits */

27   *cp-- = (signum % 10) + '0';

28   signum /= 10;

29  }

30  strcat(buf, "\n");

31  (void)write(2, buf, strlen(buf));

32 }

33

34 /* main --- установить обработку сигнала и войти в бесконечный цикл */

35

36 int main(void)

37 {

38  (void)signal(SIGINT, handler);

39

40  for(;;)

41   pause(); /* ждать сигнал, см. далее в главе */

42

43  return 0;

44 }

Строки 9–22 определяют функцию обработки сигнала (остроумно названную handler()). Все, что эта функция делает, — выводит номер перехваченного сигнала и возвращается. Для вывода этого сообщения она выполняет множество ручной работы, поскольку fprintf() не является «безопасной» для вызова из обработчика сигнала. (Вскоре это будет описано в разделе 10.4.6 «Дополнительные предостережения».)

Функция main() устанавливает обработчик сигнала (строка 38), а затем входит в бесконечный цикл (строки 40–41). Вот что происходит при запуске:

$ ssh solaris.example.com

 /* Зарегистрироваться на доступной системе Solaris */

Last login: Fri Sep 19 04:33:25 2003 from 4.3.2.1.

Sun Microsystems Inc. SunOS 5.9 Generic May 2002

$ gcc ch10-catchint.c /* Откомпилировать программу */

$ a.out /* Запустить ее */

^C  handler: caught signal 2 /* Набрать ^C, вызывается обработчик */

^C /* Попробовать снова, но на этот раз... */

$ /* Программа завершается */

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

void handler(int signum) {

 char buf[200], *cp;

 int offset;

 (void)signal(signum, handler); /* переустановить обработчик */

 /* ...оставшаяся часть функции как прежде... */

}

 

10.4.2. BSD и GNU/Linux

BSD 4.2 изменила способ работы signal(). На системах BSD обработчик сигнала после его возвращения остается на месте. Системы GNU/Linux следуют поведению BSD. Вот что происходит под GNU/Linux:

$ ch10-catchint           /* Запустить программу */

handler: caught signal 2 /* Набираем ^C, вызывается обработчик */

handler: caught signal 2 /* И снова... */

handler: caught signal 2 /* И снова! */

handler: caught signal 2 /* Помогите! */

handler: caught signal 2 /* Как нам это остановить?! */

Quit (core dumped)       /* ^\, генерирует SIGQUIT. Bay */

На системе BSD или GNU/Linux обработчик сигнала не должен дополнительно использовать 'signal(signum, handler)' для переустановки обработчика. Однако, лишний вызов не причиняет никакого вреда, поэтому сохраняется статус-кво.

В действительности, POSIX предоставляет функцию bsd_signal(), которая идентична signal() за тем исключением, что она гарантирует, что обработчик сигнала останется установленным:

#include /* XSI, устаревает */

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

Это устраняет проблемы переносимости. Если вы знаете, что ваша программа будет работать лишь на системах POSIX, вы можете воспользоваться bsd_signal() вместо signal().

Одно предостережение — эта функция также помечена как «устаревающая», что означает возможность отказа от нее в будущем стандарте. На практике, даже если от нее откажутся, поставщики скорее всего долгое время будут ее поддерживать. (Как мы увидим, функция API POSIX sigaction() предоставляет достаточно возможностей для написания рабочей версии, если это вам нужно.)

 

10.4.3. Игнорирование сигналов

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

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

/* Обработка прерываний и отсоединений. Упрощена для представления */

static void sighandler(int sig) {

 signal(sig, SIG_IGN); /* Отныне этот сигнал игнорировать */

 cleanup();            /* Очистка после себя */

 signal(sig, SIG_DFL); /* Восстановление действия по умолчанию */

 raise(sig);           /* Повторно отправить сигнал */

}

Установка действия SIG_IGN гарантирует, что все последующие появляющиеся сигналы SIGINT не повлияют на продолжающийся процесс очистки. Когда функция cleanup() завершит работу, восстановление действия SIG_DFL позволяет системе сделать снимок образа процесса, если это нужно возникшему сигналу. Вызов raise() восстанавливает сигнал. Затем восстановленный сигнал вызывает действие по умолчанию, которое, скорее всего, завершит программу. (Далее в этой главе мы полностью покажем обработчик сигнала sort.c.)

 

10.4.4. Системные вызовы, допускающие повторный запуск

 

Значение EINTR для errno (см. раздел 4.3 «Определение ошибок») указывает, что системный вызов был прерван. Хотя с этим значением ошибки может завершаться большое количество системных вызовов, двумя наиболее значительными являются read() и write(). Рассмотрите следующий код:

void handler(int signal) { /* обработка сигналов */ }

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

 signal(SIGINT, handler);

 ...

 while ((count = read(fd, buf, sizeof buf)) > 0) {

  /* Обработка буфера */

 }

 if (count == 0)

  /* конец файла, очистка и т.п. */

 else if (count == -1)

  /* ошибка */

 ...

}

Предположим, что система успешно прочла (и заполнила) часть буфера, когда возник SIGINT. Системный вызов read() еще не вернулся из ядра в программу, но ядро решает, что оно может доставить сигнал. Вызывается handler(), запускается и возвращается в середину read(). Что возвратит read()?

В былые времена (V7, более ранние системы System V) read() возвратила бы -1 и установила бы errno равным EINTR. Не было способа сообщить, что данные были переданы. В данном случае V7 и System V действуют, как если бы ничего не случилось: не было перемещений данных в и из буфера пользователя, и смещение файла не было изменено. BSD 4.2 изменила это. Были два случая:

Медленные устройства

«Медленное устройство» является в сущности терминалом или почти всяким другим устройством, кроме обычного файла. В этом случае read() могла завершиться с ошибкой EINTR, лишь если не было передано никаких данных, когда появился сигнал. В противном случае системный вызов был бы запущен повторно, и read() возвратилась бы нормально.

Обычные файлы

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

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

Поведение POSIX сходно, но не идентично первоначальному поведению BSD. POSIX указывает, что read() завершается с ошибкой EINTR лишь в случае появления сигнала до начала перемещения данных. Хотя POSIX ничего не говорит о «медленных устройствах», на практике это условие проявляется именно на них.

В противном случае, если сигнал прерывает частично выполненную read(), возвращенное значение является числом уже прочитанных байтов. По этой причине (а также для возможности обработки коротких файлов) всегда следует проверять возвращаемое read() значение и никогда не предполагать, что прочитано все запрошенное количество байтов. (Функция POSIX API sigaction(), описанная позже, позволяет при желании получить поведение повторно вызываемых системных вызовов BSD.)

 

10.4.4.1. Пример: GNU Coreutils

safe_read()

и

safe_write()

Для обработки случая EINTR в традиционных системах GNU Coreutils использует две функции, safe_read() и safe_write(). Код несколько запутан из-за того, что один и тот же файл за счет включения #include и макросов реализует обе функции. Из файла lib/safe-read.c в дистрибутиве Coreutils:

1  /* Интерфейс read и write для .повторных запусков после прерываний.

2     Copyright (С) 1993, 1994, 1998, 2002 Free Software Foundation, Inc.

   /* ... куча шаблонного материала опущена... */

56

57 #ifdef SAFE_WRITE

58 # include "safe-write.h"

59 # define safe_rw safe_write /* Создание safe_write() */

60 # define rw write /* Использование системного вызова write() */

61 #else

62 # include "safe-read.h"

63 # define safe_rw safe_read /* Создание safe_read() */

64 # define rw read /* Использование системного вызова read() */

65 # undef const

66 # define const /* пусто */

67 #endif

68

69 /* Прочесть (записать) вплоть до COUNT байтов в BUF из(в) дескриптора FD, повторно запуская вызов при

70 прерывании. Вернуть число действительно прочитанных (записанных) байтов, 0 для EOF

71 или в случае ошибки SAFE_READ_ERROR(SAFE_WRITE_ERROR). */

72 size_t

73 safe_rw(int fd, void const *buf, size_t count)

74 {

75  ssize_t result;

76

77  /* POSIX ограничивает COUNT значением SSIZE_MAX, но мы еще больше ограничиваем его, требуя,

78  чтобы COUNT <= INT_MAX, для избежания ошибки в Tru64 5.1.

79  При уменьшении COUNT сохраняйте указатель файла выровненным по размеру блока.

80  Обратите внимание, что read (write) может быть успешным в любом случае, даже если прочитано (записано)

81  менее COUNT байтов, поэтому вызывающий должен быть готов обработать

82  частичные результаты. */

83  if (count > INT_MAX)

84   count = INT_MAX & -8191;

85

86  do

87  {

88   result = rw(fd, buf, count);

89  }

90  while (result < 0 && IS_EINTR(errno));

91

92  return (size_t) result;

93 }

Строки 57–67 обрабатывают определения, создавая соответствующим образом safe_read() и safe_write() (см. ниже safe_write.c).

Строки 77–84 указывают на разновидность осложнений, возникающих при чтении. Здесь один особый вариант Unix не может обработать значения, превышающие INT_MAX, поэтому строки 83–84 выполняют сразу две операции: уменьшают значение числа, чтобы оно не превышало INT_MAX, и сохраняют его кратным 8192. Последняя операция служит эффективности дисковых операций: выполнение ввода/вывода с кратным основному размеру дискового блока объемом данных более эффективно, чем со случайными размерами данных. Как отмечено в комментарии, код сохраняет семантику read() и write(), где возвращенное число байтов может быть меньше затребованного.

Обратите внимание, что параметр count может и в самом деле быть больше INT_MAX, поскольку count представляет тип size_t, который является беззнаковым (unsigned). INT_MAX является чистым int, который на всех современных системах является знаковым.

Строки 86–90 представляют действительный цикл, повторно осуществляющий операцию, пока она завершается ошибкой EINTR. Макрос IS_EINTR() не показан, но он обрабатывает случай в системах, на которых EINTR не определен. (Должен быть по крайней мере один такой случай, иначе код не будет возиться с установкой макроса; возможно, это было сделано для эмуляции Unix или POSIX в не-Unix системе.) Вот safe_write.c:

1  /* Интерфейс write для повторного запуска после прерываний.

2     Copyright (С) 2002 Free Software Foundation, Inc.

   /* ...куча шаблонного материала опущена... */

17

18 #define SAFE_WRITE

19 #include "safe-read.с"

В строке 18 #define определяет SAFE_WRITE; это связано со строками 57–60 в safe_read.с.

 

10.4.4.2. Только GLIBC:

TEMP_FAILURE_RETRY()

Файл GLIBC определяет макрос TEMP_FAILURE_RETRY(), который вы можете использовать для инкапсулирования любого системного вызова, который может при неудачном вызове установить errno в EINTR. Его «объявление» следующее:

#include /* GLIBC */

long int TEMP_FAILURE_RETRY(expression);

Вот определение макроса:

/* Оценить EXPRESSION и повторять, пока оно возвращает -1 с 'errno',

    установленным в EINTR. */

# define TEMP_FAILURE_RETRY(expression) \

 (__extension__ \

  ({ long int __result; \

   do __result = (long int)(expression); \

   while (__result == -1L && errno == EINTR); \

   __result; }))

Макрос использует расширение GCC к языку С (как обозначено ключевым словом __extension__), которое допускает заключенным в фигурные скобки внутри обычных скобок выражениям возвращать значение, действуя таким образом подобно простому выражению.

Используя этот макрос, мы могли бы переписать safe_read() следующим образом:

size_t safe_read(int fd, void const *buf, size_t count) {

 ssize_t result;

 /* Ограничить count, как в ранее приведенном комментарии. */

 if (count > INT_MAX)

  count = INT_MAX & ~8191;

 result = TEMP_FAILURE_RETRY(read(fd, buf, count));

 return (size_t)result;

}

 

10.4.5. Состояния гонок и

sig_atomic_t

(ISO C)

Пока обработка одного сигнала за раз выглядит просто: установка обработчика сигнала в main() и (не обязательная) переустановка самого себя обработчиком сигнала (или установка действия SIG_IGN) в качестве первого действия обработчика.

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

Или предположим, что вы используете bsd_signal(), так что обработчик остается установленным, но второй сигнал отличается от первого? Обычно обработчику первого сигнала нужно завершить свою работу до того, как запускается второй, а каждый обработчик сигнала не должен временно игнорировать все прочие возможные сигналы!

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

int sig_int_flag = 0; /* обработчик сигнала устанавливает в true */

void int_handler(int signum) {

 sig_int_flag = 1;

}

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

 bsd_signal(SIGINT, int_handler);

 /* ...программа продолжается... */

 if (sig_int_flag) {

  /* возник SIGINT, обработать его */

 }

 /* ...оставшаяся логика... */

}

(Обратите внимание, что эта стратегия уменьшает окно уязвимости, но не устраняет его).

Стандарт С вводит специальный тип — sig_atomic_t — для использования с такими флаговыми переменными. Идея, скрывающаяся за этим именем, в том, что присвоение значений переменным этого типа является атомарной операцией: т.е. они совершаются как одно делимое действие. Например, на большинстве машин присвоение значения int осуществляется атомарно, тогда как инициализация значений в структуре осуществляется либо путем копирования всех байтов в (сгенерированном компилятором) цикле, либо с помощью инструкции «блочного копирования», которая может быть прервана. Поскольку присвоение значения sig_atomic_t является атомарным, раз начавшись, оно завершается до того, как может появиться другой сигнал и прервать его.

Наличие особого типа является лишь частью истории. Переменные sig_atomic_t должны быть также объявлены как volatile:

volatile sig_atomic_t sig_int_flag = 0; /* обработчик сигнала устанавливает в true */

/* ...оставшаяся часть кода как раньше... */

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

Структурирование приложения исключительно вокруг переменных sig_atomic_t ненадежно. Правильный способ обращения с сигналами показан далее, в разделе 10.7 «Сигналы для межпроцессного взаимодействия».

 

10.4.6. Дополнительные предостережения

Стандарт POSIX предусматривает для обработчиков сигналов несколько предостережений:

• Что случается, когда возвращаются обработчики для SIGFPE, SIGILL, SIGSEGV или любых других сигналов, представляющих «вычислительные исключения», не определено.

• Если обработчик был вызван в результате вызова abort(), raise() или kill(), он не может вызвать raise(). abort() описана в разделе 12.4 «Совершение самоубийства: abort()», a kill() описана далее в этой главе. (Описанная далее функция API sigaction() с обработчиком сигнала, принимающая три аргумента, дает возможность сообщить об этом, если это имеет место.)

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

Список в табл. 10.2 происходит из раздела 2.4 тома System Interfaces (Системные интерфейсы) стандарта POSIX 2001. Многие из этих функций относятся к сложному API и больше не рассматриваются в данной книге.

Таблица 10.2. Функции, которые могут быть вызваны из обработчика сигнала

_Exit() fpathconf() raise() sigqueue()
_exit() fstat() read() sigset()
accept() fsync() readlink() sigsuspend()
access() ftruncate() recv() sleep()
aio_error() getegid() recvfrom() socket()
aio_return() geteuid() recvmsg() socketpair()
aio_suspend() getgid() rename() stat()
alarm() getgroups() rmdir() sysmlink()
bind() getpeername() select() sysconf()
cfgetispeed() getpgrp() sem_post() tcdrain()
cfgetospeed() getpid() send() tcflow()
cfsetispeed() getppid() sendmsg() tcflush()
cfsetospeed() getsockname() sendto() tcgetattr()
chdir() getsockopt() setgid() tcgetpgrp()
chmod() getuid() setpgid() tcsendbreak()
chown() kill() setsid() tcsetattr()
clock_gettime() link() setsockopt() tcsetpgrp()
close() listen() setuid() time()
connect() lseek() shutdown() timer_getoverrun()
creat() lstat() sigaction() timer_gettime()
dup() mkdir() sigaddset() timer_settime()
dup2() mkfifo() sigdelset() times()
execle() open() sigemptyset() umask()
execve() pathconf() sigfillset() uname()
fchmod() pause() sigismember() unlink()
fchown() pipe() signal() utime()
fcntl() poll() sigpause() wait()
fdatasync() posix_trace_event() sigpending() waitpid()
fork() pselect() sigprocmask() write()

 

10.4.7. Наша история до настоящего времени, эпизод 1

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

• Сигналы являются указанием того, что произошло некоторое внешнее событие.

• raise() является функцией ISO С для отправки сигнала текущему процессу. Как отправлять сигналы другим процессам, нам еще предстоит описать.

• signal() контролирует диспозицию сигнала, т.е. реакцию процесса на сигнал, когда он появляется. Сигнал можно оставить системе для обработки по умолчанию, проигнорировать или перехватить.

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

 • ISO С не определяет, восстанавливается ли диспозиция сигнала по умолчанию до вызова обработчика или она остается на месте. Первое является поведением V7 и современных систем System V, таких, как Solaris. Последнее является поведением BSD, используемым также в GNU/Linux. (Для форсирования поведения BSD может использоваться функция POSIX bsd_signal().)

• То, что случается при прерывании сигналом системного вызова, также различается в традиционной и BSD линейках. Традиционные системы возвращают -1 с errno, установленным в EINTR. BSD системы повторно запускают системный вызов после возвращения из обработчика. Макрос GLIBC TEMP_FAILURE_RETRY() может помочь вам написать код для обработки системных вызовов, возвращающих -1 с errno, установленным в EINTR.

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

• Механизм signal() предоставляет плодотворную почву для появления условий гонки. В этой ситуации помогает тип данных ISO С sig_atomic_t, но он не решает проблему, и определенный таким способом механизм не может обезопасить от проявления условий гонки.

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

Несмотря на эти проблемы интерфейса signal() для простых программ достаточно, и он все еще широко используется.

 

10.5. API сигналов System V Release 3:

sigset()

и др.

BSD 4.0 (примерно с 1980 г.) ввел дополнительные функции API для предоставления «надежных» сигналов. В частности, стало возможным блокировать сигналы. Другими словами, программа могла сообщить ядру: «Зависни на этих конкретных сигналах в течении следующего небольшого промежутка времени, затем доставь их мне, когда я буду готов их принять». Большим преимуществом является то, что эта особенность упрощает обработчики сигналов, которые автоматически запускаются со своим заблокированным сигналом (чтобы избежать проблемы одновременной обработки двух сигналов) и, возможно, также и с другими заблокированными сигналами.

System V Release 3 (примерно с 1984 г.) приняла эти API и популяризовала их, в большинстве связанных с Unix документации и книгах вы, возможно, увидите, что на эти API ссылаются, как ведущие начало от System V Release 3. Эти функции следующие:

#include /* XSI */

int sighold(int sig); /* Добавить sig к маске сигналов процесса */

int sigrelse(int sig); /* Удалить sig из маски сигналов процесса */

int sigignore(int sig); /* Сокращение для sigset(sig, SIG_IGN) */

int sigpause(int sig);

 /* Приостановить процесс, позволить появиться sig */

void (*sigset(int sig, void (*disp)(int)))(int);

 /* sighandler_t sigset(int sig, sighandler_t disp); */

Стандарт POSIX для этих функций описывает их поведение в терминах маски сигналов процесса. Маска сигналов процесса отслеживает, какие сигналы (если они вообще есть) процесс заблокировал в настоящее время. Более подробно это описывается в разделе 10.6.2 «Наборы сигналов: sigset_t и связанные функции». В API System V Release 3 нет способа получить или изменить маску сигналов процесса в целом. Функции работают следующим образом:

int sighold(int sig)

Добавляет sig к списку заблокированных процессов (маска сигналов процесса).

int sigrelse(int sig)

Удаляет sig из маски сигналов процесса.

int sigignore(int sig)

Игнорирует sig. Это вспомогательная функция.

int sigpause(int sig)

Удаляет sig из маски сигналов процесса, а затем приостанавливает процесс до появления сигнала (см. раздел 10.7 «Сигналы для межпроцессного взаимодействия»).

sighandler_t sigset(int sig, sighandler_t disp)

Это замена для signal(). (Здесь мы использовали обозначение из справочной страницы GNU/Linux, чтобы упростить восприятие объявления функции.)

Для sigset() аргумент handler может быть SIG_DFL, SIG_IGN или указатель функции, как и для signal(). Однако, он может равняться также и SIG_HOLD. В этом случае sig добавляется к маске сигналов процесса, но связанное с ним действие никак не изменяется. (Другими словами, если бы у него был обработчик, он остается тем же; если было действие по умолчанию, оно не изменяется.)

Когда для установки обработчика сигнала используется sigset() и появляется сигнал, ядро сначала добавляет сигнал к маске процессов сигнала, блокируя любой дальнейший прием этого сигнала. Запускается обработчик, а когда он возвращается, ядро восстанавливает маску сигналов процесса в то состояние, какое было до запуска обработчика. (В модели POSIX если обработчик сигнала изменяет маску сигнала, это изменение переписывается в процессе восстановления предыдущей маски, когда обработчик возвращается.)

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

ЗАМЕЧАНИЕ . POSIX стандартизует эти API, поскольку главной целью POSIX является формализация существующей практики, где это возможно. Однако, функции sigaction() , которые вскоре будут описаны, дают вам все, что делают эти API, и даже больше. В новых программах вам не следует использовать эти API Вместо этого используйте sigaction() . (Мы заметили, что в справочной системе GNU/Linux нет даже страницы для sigset (2)!)

 

10.6. Сигналы POSIX

 

API POSIX основан на API sigvec() из BSD 4.2 и 4.3. С небольшими изменениями этот API можно было отнести к возможностям API как V7, так и System V Release 3. POSIX сделал эти изменения и переименовал API sigaction(). Поскольку интерфейс sigvec() широко не использовался, мы не будем его описывать. Вместо этого в данном разделе описывается только sigaction(), который вы и должны так или иначе использовать. (На самом деле руководства BSD 4.4 от 1994 г. помечают sigvec() как устаревшую, указывая читателю на sigaction().)

 

10.6.1. Обнажение проблемы

Что неладно с API System V Release 3? В конце концов, они предоставляют блокирование сигналов, так, что сигналы не теряются, и любой данный сигнал может быть надежно обработан.

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

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

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

 

10.6.2. Наборы сигналов:

sigset_t

и связанные функции

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

Маска сигналов процесса программно представляется с помощью набора сигналов. Это тип sigset_t. Концептуально он представляет собой просто битовую маску, причем значения 0 и 1 представляют отсутствие или наличие определенного сигнала в маске.

/* Непосредственное манипулирование маской сигналов. НЕ ДЕЛАЙТЕ ЭТОГО! */

int mask = (1 << SIGHUP) | (1 << SIGINT);

 /* битовая маска для SIGHUP и SIGINT */

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

#include /* POSIX */

int sigemptyset(sigset_t *set);

int sigfillset(sigset_t *set);

int sigaddset(sigset_t *set, int signum);

int sigdelset(sigset_t *set, int signum);

int sigismember(const sigset_t *set, int signum);

Эти функции следующие:

int sigemptyset(sigset_t *set)

Освобождает набор сигналов. По возвращении *set не содержит сигналов. Возвращает 0 в случае успеха и -1 при ошибке.

int sigfillset(sigset_t *set)

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

int sigaddset(sigset_t *set, int signum)

Добавляет signum к маске сигналов процесса в *set. Возвращает 0 в случае успеха и -1 при ошибке.

int sigdelset(sigset_t *set, int signum)

Удаляет signum из маски сигналов процесса в *set. Возвращает 0 в случае успеха и -1 при ошибке.

int sigismember(const sigset_t *set, int signum)

Возвращает true/false, если signum присутствует или не присутствует в *set.

Перед выполнением с переменной sigset_t каких-то действий всегда следует вызывать одну из функций sigemptyset() или sigfillset(). Существуют оба интерфейса, поскольку иногда бывает нужно начать с пустого набора и работать потом лишь с одним или двумя сигналами, а в другое время бывает нужно работать со всеми сигналами, возможно, убирая один или два сигнала.

 

10.6.3. Управление маской сигналов:

sigprocmask()

и др.

Маска сигналов процесса вначале пуста - заблокированных сигналов нет. (Это упрощение; см. раздел 10.9 «Сигналы, передающиеся через fork() и exec().) Три функции позволяют работать непосредственно с маской сигналов процесса:

#include /* POSIX */

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

int sigpending(sigset_t *set);

int sigsuspend(const sigset_t *set);

Функции следующие:

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)

Если oldset не равен NULL, получается маска сигналов текущего процесса и помещается в *oldset. Затем маска сигналов процесса обновляется в соответствии с содержимым set и значением how, который должен иметь одно из следующих значений:

SIG_BLOCK  Объединить сигналы в *set с маской сигналов текущего процесса. Новая маска является объединением текущей маски и *set.

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

SIG_SETMASK  Заменить маску сигналов процесса содержимым *set.

Если set равен NULL, a oldset — нет, значение how неважно. Эта комбинация получает маску сигналов текущего процесса, не меняя ее. (Это явно выражено в стандарте POSIX, но не ясно из справочной страницы GNU/Linux.)

int sigpending(sigset_t *set)

Эта функция позволяет увидеть, какие сигналы ожидают решения; т.е. *set заполнен этими сигналами, которые были посланы, но они еще не доставлены, поскольку заблокированы.

int sigsuspend(const sigset_t *set)

Эта функция временно заменяет маску сигналов процесса содержимым *set, а затем приостанавливает процесс, пока сигнал не будет получен. По определению, заставить функцию вернуться может только сигнал, не находящийся в *set (см. раздел 10.7 «Сигналы для межпроцессного взаимодействия).

 

10.6.4. Перехват сигналов:

sigaction()

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

#include /* POSIX */

int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

Аргументы следующие:

int signum

Интересующий сигнал, как в случае с другими функциями обработки сигналов.

const struct sigaction *act

Определение нового обработчика для сигнала signum.

struct sigaction *oldact

Определение текущего обработчика. Если не NULL, система до установки *act заполняет *oldact. *act может быть NULL, в этом случае *oldact заполняется, но больше ничего не меняется.

Таким образом, sigaction() и устанавливает новый обработчик, и получает старый за одно действие. struct sigaction выглядит следующим образом.

/* ПРИМЕЧАНИЕ: Порядок в структуре может варьировать. Могут быть

   также и другие поля! */

struct sigaction {

 sigset_t sa_mask; /* Дополнительные сигналы для блокирования */

 int sa_flags;     /* Контролирует поведение */

 void (*sa_handler)(int);

  /* Может образовать объединение с sa_sigaction */

 void (*sa_sigaction)(int, siginfo_t*, void*);

  /* Может образовать объединение с sa_handler */

}

Поля следующие:

sigset_t sa_mask

Набор дополнительных сигналов для блокирования при запуске функции обработчика. Таким образом, когда вызывается обработчик, общий набор заблокированных сигналов является объединением сигналов в маске процесса, сигналов в act->mask и, если SA_NODEFER сброшен, signum.

int sa_flags

Флаги, контролирующие обработку сигнала ядром. См. обсуждение далее.

void (*sa_handler)(int)

Указатель на «традиционную» функцию обработчика. У нее такой же прототип (возвращаемый тип и список параметров), как у функции обработчика для signal(), bsd_signal() и sigset().

void (*sa_sigaction)(int, siginfo_t*, void*)

Указатель на функцию обработчика «нового стиля». Функция принимает три аргумента, которые вскоре будут описаны.

Которая из функций act->sa_handler и act->sa_sigaction используется, зависит от флага SA_SIGINFO в act->sa_flags. Когда имеется, используется act->sa_sigaction; в противном случае используется act->sa_handler. Как POSIX, так и справочная страница GNU/Linux указывают, что эти два поля могут перекрываться в памяти (т. е. быть частью union). Таким образом, никогда не следует использовать оба поля в одной и той же struct sigaction.

Поле sa_flags составляется с помощью побитового ИЛИ значений одного или более флагов, перечисленных в табл. 10.3.

Таблица 10.3. Значения флагов для sa_flags

Флаг Значение
SA_NOCLDSTOP Этот флаг имеет смысл лишь для SIGCHLD . Когда он установлен, родитель не получает сигнал при остановке порожденною процесса сигналами SIGSTOP , SIGTSTP , SIGTTIN или SIGTTOU . Эти сигналы обсуждаются позже, в разделе 10.8.2
SA_NOCLDWAIТ Этот флаг имеет смысл лишь для SIGCHLD . Его поведение сложно. Мы отложим объяснение на потом, см. раздел 10.8.3
SA_NODEFER Обычно данный сигнал блокируется, когда вызывается обработчик сигнала. Когда установлен один из этих флагов, данный сигнал не блокируется при запуске обработчика SA_NODEFER является официальным именем POSIX данного флага (которое и следует использовать)
SA_NOMASK Альтернативное имя для SA_NODEFER [110]
SA_SIGINFO Обработчик сигнала принимает три аргумента. Как упоминалось, при данном установленном флаге должно использоваться поле sa_sigaction вместо sa_handler .
SA_ONSTACK Это продвинутая возможность. Обработчики сигналов могут вызываться с использованием предоставленной пользователем памяти в качестве «альтернативного стека сигнала». Эта память даётся ядру для подобного использования посредством sigaltstack() (см. sigaltstack (2)). Эта особенность больше не описывается в данной книге
SA_RESETHAND Этот флаг обеспечивает поведение V7: после вызова обработчика восстанавливается действие сигнала по умолчанию. Официальным именем POSIX флага (которое следует использовать) является SA_RESETHAND
SA_ONESHOT Альтернативное имя для SA_RESETHAND.
SA_RESTART Этот флаг предоставляет семантику BSD: системные вызовы, которые могут завершиться с ошибкой EINTR и которые получают этот сигнал, запускаются повторно.

Когда в act->sa_flags установлен флаг SA_SIGINFO, поле act->sa_sigaction является указателем на функцию, объявленную следующим образом:

void action_handler(int sig, siginfo_t *info, void *context) {

 /* Здесь тело обработчика */

}

Структура siginfo_t предоставляет изобилие сведений о сигнале:

/* Определение POSIX 2001. Действительное содержание может на разных системах быть разным. */

typedef struct {

 int si_signo;  /* номер сигнала */

 int si_errno;  /* значение при ошибке */

 int si_code;   /* код сигнала; см. текст */

 pid_t si_pid;  /* ID процесса, пославшего сигнал */

 uid_t si_uid;  /* настоящий UID посылающего процесса */

 void *si_addr; /* адрес вызвавшей ошибку инструкции */

 int si_status; /* значение завершения, может включать death-by-signal */

 long si_band;  /* связывающее событие для SIGPOLL/SIGIO */

 union sigval si_value; /* значение сигнала (расширенное) */

} siginfo_t;

Поля si_signo, si_code и si_value доступны для всех сигналов. Другие поля могут быть членами объединения, поэтому должны использоваться лишь для тех сигналов, для которых они определены. В структуре siginfo_t могут быть также и другие поля.

Почти все поля предназначены для расширенного использования. Все подробности содержатся в стандарте POSIX и справочной странице sigaction(2). Однако, мы можем описать простое использование поля si_code.

Для SIGBUS, SIGCHLD, SIGFPE, SIGILL, SIGPOLL, SIGSEGV и SIGTRAP поле si_code может принимать любое из набора предопределенных значений, специфичных для каждого сигнала, указывая на причину появления сигнала. Откровенно говоря, детали несколько чрезмерны; повседневному коду на самом деле нет необходимости иметь с ними дела (хотя позже мы рассмотрим значения для SIGCHLD). Для всех остальных сигналов член si_code имеет одно из значений из табл. 10.4.

Таблица 10.4. Значения происхождения сигнала для si_code

Значение Только GLIBC Смысл
SI_ASYNCIO Асинхронный ввод/вывод завершен (расширенный).
SI_KERNEL Сигнал послан ядром.
SI_MESGQ Состояние очереди сообщений изменилось (расширенный.)
SI_QUEUE Сигнал послан из sigqueue() (расширенный).
SI_SIGIO SIGIO поставлен в очередь (расширенный).
SI_TIMER Время таймера истекло
SI_USER Сигнал послан функцией kill() . raise() и abort() также могут его вызвать, но это не обязательно.

В особенности полезно значение SI_USER; оно позволяет обработчику сигнала сообщить, был ли сигнал послан функциями raise() или kill() (описываются далее). Вы можете использовать эту информацию, чтобы избежать повторного вызова raise() или kill().

Третий аргумент обработчика сигнала с тремя аргументами, void *context, является расширенной возможностью, которая больше не обсуждается в данной книге.

Наконец, чтобы увидеть sigaction() в действии, исследуйте полный исходный код обработчика сигнала для sort.c:

2074 static void

2075 sighandler(int sig)

2076 {

2077 #ifndef SA_NOCLDSTOP /* В системе старого стиля... */

2078  signal(sig, SIG_IGN); /* - для игнорирования sig используйте signal()*/

2079 #endif - /* В противном случае sig автоматически блокируется */

2080

2081  cleanup(); /* Запуск кода очистки */

2082

2083 #ifdef SA_NOCLDSTOP /* В системе в стиле POSIX... */

2084  {

2085   struct sigaction sigact;

2086

2087   sigact.sa_handler = SIG_DFL; /* - Установить действие по умолчанию */

2088   sigemptyset(&sigact.sa_mask); /* - Нет дополнительных сигналов для блокирования */

2089   sigact.sa_flags = 0; /* - Специальные действия не предпринимаются */

2090   sigaction(sig, &sigact, NULL); /* - Поместить на место */

2091  }

2092 #else /* На системе в старом стиле... */

2093  signal(sig, SIG_DFL); /* - Установить действие по умолчанию */

2094 #endif

2095

2096  raise(sig); /* Повторно послать сигнал */

2097 }

Вот код в main(), который помещает обработчик на свое место:

2214 #ifdef SA_NOCLDSTOP /* На системе POSIX... */

2215 {

2216  unsigned i;

2217  sigemptyset(&caught_signals);

2218  for (i = 0; i < nsigs; i++) /* - Блокировать все сигналы */

2219   sigaddset(&caught_signals, sigs[i]);

2220  newact.sa_handler = sighandler; /* - Функция обработки сигнала */

2221  newact.sa_mask = caught_signals; /* - Установить для обработчика маску сигналов процесса */

2222  newact.sa_flags =0; /* - Особых флагов нет */

2223 }

2224 #endif

2225

2226 {

2227  unsigned i;

2228  for (i = 0; i < nsigs; i++) /* Для всех сигналов... */

2229  {

2230   int sig = sigs[i];

2231 #ifdef SA_NOCLDSTOP

2232   sigaction(sig, NULL, &oldact); /* - Получить старый обработчик */

2233   if (oldact.sa_handler != SIG_IGN) /* - Если этот сигнал не игнорируется */

2234    sigaction(sig, &newact, NULL); /* - Установить наш обработчик */

2235 #else

2236   if (signal(sig, SIG_IGN) != SIG_IGN)

2237    signal(sig, sighandler); /* - Та же логика со старым API */

2238 #endif

2239  }

2240 }

Мы заметили, что строки 2216–2219 и 2221 могут быть замещены одним вызовом: sigfillset(&newact.sa_mask);

Мы не знаем, почему код написан именно таким способом.

Интерес представляют также строки 2233–2234 и 2236–2237, которые показывают правильный способ проверки того, игнорируется ли сигнал, и для установки обработчика лишь в том случае, если сигнал не игнорируется.

ЗАМЕЧАНИЕ . Функции API sigaction() и signal() не должны использоваться вместе для одного и того же сигнала. Хотя POSIX идет на большие длинноты, чтобы сначала сделать возможным использование signal() , получить struct sigaction , представляющую диспозицию signal() , и восстановить ее, все равно это плохая мысль. Код будет гораздо проще читать, писать и понимать, если вы используете одну функцию или другую взаимоисключающим образам

 

10.6.5. Извлечение ожидающих сигналов:

sigpending()

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

#include /* POSIX */

int sigpending(sigset_t *set);

Помимо разблокировки ожидающих сигналов, чтобы они могли быть доставлены, вы можете решить их игнорировать. Установка действия сигнала SIG_IGN вызывает сбрасывание сигнала (даже если он был заблокирован). Сходным образом для тех сигналов, действием по умолчанию для которых является их игнорирование, установка действия в SIG_DFL также вызывает сбрасывание таких ожидающих сигналов.

 

10.6.6. Создание возможности для прерывания функций:

siginterrupt()

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

#include /* XSI */

int siginterrupt(int sig, int flag);

В соответствии со стандартом POSIX поведение siginterrupt() эквивалентно следующему коду:

int siginterrupt(int sig, int flag) {

 int ret;

 struct sigaction act;

 (void)sigaction(sig, NULL, &act); /* Получить старые установки */

 if (flag) /* Если flag равен true... */

  act.sa_flags &= ~SA_RESTART; /* Запретить повторный запуск */

 else /* В противном случае... */

  act.sa_flags |= SA_RESTART; /* Разрешить повторный запуск */

 ret = sigaction(sig, &act, NULL);

  /* Поместить новые установки на место */

 return ret; /* Вернуть результат */

}

В случае успеха возвращаемое значение равно 0 и -1 при ошибке.

 

10.6.7. Передача сигналов:

kill()

и

killpg()

Традиционная функция Unix для передачи сигналов называется kill(). Имя несколько неправильное; все, что она делает — отправляет сигнал. (Результатом этого часто является завершение получателя сигнала, но это не обязательно верно. Однако, теперь слишком поздно менять имя.) Функция killpg() посылает сигнал определенной группе процессов. Объявления следующие:

#include /* POSIX */

#include

int kill(pid_t pid, int sig);

int killpg(int pgrp, int sig); /* XSI */

Аргумент sig является либо именем сигнала, либо 0. В последнем случае сигнал не посылается, но ядро все равно осуществляет проверку ошибок. В частности, это правильный способ проверки существования данного процесса или группы, а также проверки того, что у вас есть разрешение на передачу сигналов процессу или группе процессов kill() возвращает 0 в случае успеха и -1 при ошибке; errno указывает на проблему.

Правила для значения pid несколько запутаны:

pid > 0   pid является номером процесса, и сигнал посылается этому процессу

pid = 0   Сигнал посылается каждому процессу в группе посылающего процесса.

pid = -1  Сигнал посылается каждому процессу в системе, за исключением специальных системных процессов. Применяется проверка прав доступа. На системах GNU/Linux исключается лишь процесс init (PID 1), но у других систем могут быть другие специальные процессы.

pid < -1  Сигнал посылается группе процессов, представленной абсолютным значением pid. Таким образом, вы можете отправить сигнал всей группе процессов, дублируя возможности killpg(). Эта неортогональность обеспечивает историческую совместимость.

Значение pid для kill() сходно со значением для waitpid() (см. раздел 9.1.6.1 «Использование функций POSIX: wait() и waitpid()»).

Стандартная функция С raise() в сущности эквивалентна

int raise(int sig) {

 return kill(getpid(), sig);

}

Комитет по стандартизации С выбрал имя raise(), поскольку С должен работать также в окружениях, не относящихся к Unix, a kill() была сочтена специфичной для Unix функцией. Представилась также возможность дать этой функции более описательное имя.

killpg() посылает сигнал группе процессов. Пока значение pgrp превышает 1, эта функция эквивалентна 'kill(-pgrp, sig)'. Справочная страница GNU/Linux killpg(2) утверждает, что если pgrp равно 0, сигнал посылается группе отправляющего процесса (Это то же самое, что и kill().)

Как вы могли представить, нельзя послать сигнал произвольному процессу (если вы не являетесь суперпользователем, root). Для обычных пользователей действительный или эффективный UID отправляющего процесса должен соответствовать действительному или сохраненному set-user-ID получающего процесса. (Различные UID описаны в разделе 11.1.1 «Действительные и эффективные ID».)

Однако SIGCONT является особым случаем: пока получающий процесс является членом того же сеанса, что и отправляющий, сигнал пройдет. (Сеансы были кратко описаны в разделе 9.2.1 «Обзор управления заданиями».) Это особое правило позволяет управляющей заданиями оболочке продолжать остановленные процессы-потомки, даже если этот остановленный процесс имеет другой ID пользователя.

 

10.6.8. Наша история до настоящего времени, эпизод II

System V Release 3 API был предназначен для исправления различных проблем, представленных первоначальным API сигналов V7. В частности, важной дополнительной концепцией является понятие о блокировке сигналов.

Однако, этот API оказался недостаточным, поскольку он работал лишь с одним сигналом за раз, оставляя множество широко открытых окон, через которые могли поступать нежелательные сигналы. POSIX API, работая атомарно с множеством сигналов (маской сигналов процесса, программно представленной типом sigset_t), решает эту проблему, закрывая окна.

Первый набор функций, который мы исследовали, манипулирует значениями sigset_t: sigfillset(), sigemptyset(), sigaddset(), sigdelset() и sigismember().

Следующий набор работает с маской сигналов процесса: sigprocmask() устанавливает и получает маску сигналов процесса, sigpending() получает набор ожидающих сигналов, a sigsuspend() помещает процесс в состояние сна, временно заменяя маску сигналов процесса одним из своих параметров.

Функция POSIX API sigaction() (весьма) запутана из-за необходимости обеспечить:

• обратную совместимость: SA_RESETHAND и SA_RESTART в поле sa_flags;

• выбор, блокировать также полученный сигнал или нет: SA_NODEFER для sa_flags;

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

• выбор поведения для управления SIGCHLD: SA_NOCLDSTOP и SA_NOCLDWAIT для sa_flags.

Функция siginterrupt() является удобной для разрешения или запрещения повторного запуска системных вызовов для данного сигнала.

Наконец, для посылки сигналов не только текущему, но также и другим процессам могут использоваться kill() и killpg() (конечно, с проверкой прав доступа).

 

10.7. Сигналы для межпроцессного взаимодействия

Одним из главных механизмов межпроцессного взаимодействия (IPC) являются каналы, которые описаны в разделе 9.3 «Базовая межпроцессная коммуникация каналы и FIFO». Сигналы также можно использовать для очень простого IPC. Это довольно грубо; получатель может лишь сказать, что поступил определенный сигнал. Хотя функция sigaction() позволяет получателю узнать PID и владельца процесса, пославшего сигнал, эти сведения обычно не очень помогают.

ЗАМЕЧАНИЕ . Как указывает цитата в начале, использование сигналов для IPC почти всегда является плохой мыслью. Мы рекомендуем по возможности избегать этого. Но нашей целью является научить вас, как использовать возможности Linux/Unix, включая их отрицательные моменты, оставляя за вами принятие информированного решения, что именно использовать.

Сигналы в качестве IPC для многих программ могут быть иногда единственным выбором. В частности, каналы не являются альтернативой, если две взаимодействующие программы не запущены общим родителем, а файлы FIFO могут не быть вариантом, если одна из взаимодействующих программ работает лишь со стандартными вводом и выводом. (Примером обычного использования сигналов являются определенные системные программы демонов, таких, как xinetd, которые принимают несколько сигналов, уведомляющих, что нужно повторно прочесть файл настроек, осуществить проверку непротиворечивости и т.д. См. xinetd(8) в системе GNU/Linux и inetd(8) в системе Unix.)

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

for(;;){

 /* Ожидание сигнала */

 /* Обработка сигнала */

}

Оригинальным интерфейсом V7 для ожидания сигнала является pause():

#include /* POSIX */

int pause(void);

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

Проблема в только что описанной высокоуровневой структуре приложения кроется в части «Обработка сигнала». Когда этот код запускается, вы не захотите обрабатывать другой сигнал; вы хотите завершить обработку текущего сигнала до перехода к следующему. Одним из возможных решений является структурирование обработчика сигнала таким образом, что он устанавливает флаг и проверяет его в главном цикле: volatile sig_atomic_t signal_waiting = 0; /* true, если не обрабатываются сигналы */

void handler(int sig) {

 signal_waiting = 1;

 /* Установка других данных, указывающих вид сигнала */

В основном коде флаг проверяется:

for (;;) {

 if (!signal_waiting) { /* Если возник другой сигнал, */

  pause(); /* этот код пропускается */

  signal_waiting = 1;

 }

 /* Определение поступившего сигнала */

 signal_waiting = 0;

 /* Обработка сигнала */

}

К сожалению, этот код изобилует условиями гонки:

for (;;) {

 if (!signal_waiting) {

  /* <--- Сигнал может появиться здесь, после проверки условия! */

  pause(); /* pause() будет вызвана в любом случае */

  signal_waiting = 1;

 }

 /* Определение поступившего сигнала

    <--- Сигнал может переписать здесь глобальные данные */

 signal_waiting = 0;

 /* Обработка сигнала

    <--- То же и здесь, особенно для нескольких сигналов */

}

Решением является блокирование интересующего сигнала в любое время, кроме ожидания его появления. Например, предположим, что интересующим нас сигналом является SIGINT:

void handler(int sig) {

 /* sig автоматически блокируется функцией sigaction() */

 /* Установить глобальные данные, касающиеся этого сигнала */

}

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

 sigset_t set;

 struct sigaction act;

 /* ...обычная настройка, опции процесса и т.д. ... */

 sigemptyset(&set); /* Создать пустой набор */

 sigaddset(&set, SIGINT); /* Добавить в набор SIGINT */

 sigprocmask(SIG_BLOCK, &set, NULL); /* Заблокировать его */

 act.sa_mask = set; /* Настроить обработчик */

 act.sa_handler = handler;

 act.sa_flags = 0;

 sigaction(sig, &act, NULL); /* Установить его */

 ... /* Возможно, установить отдельные обработчики */

 ... /* для других сигналов */

 sigemptyset(&set); /* Восстановить пустой, допускает SIGINT */

 for (;;) {

  sigsuspend(&set); /* Ждать появления SIGINT */

  /* Обработка сигнала. SIGINT здесь снова блокируется */

 }

 /* ...любой другой код... */

 return 0;

}

Ключом к использованию этого является то, что sigsuspend() временно заменяет маску сигналов процесса маской, переданной в аргументе. Это дает SIGINT возможность появиться. При появлении он обрабатывается; обработчик сигнала возвращается, а вслед за ним возвращается также sigsuspend(). Ко времени возвращения sigsuspend() первоначальная маска процесса снова на месте.

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

При наличии всего этого не следует в новом коде использовать pause(). pause() был стандартизован POSIX главным образом для поддержки старого кода. То же самое верно и для функции sigpause() System V Release 3. Вместо этого, если нужно структурировать свое приложение с использованием сигналов для IPC, используйте исключительно функции API sigsuspend() и sigaction().

ЗАМЕЧАНИЕ . Приведенный выше код предполагает, что маска сигналов процесса начинается пустой. Код изделия должен вместо этого работать с любой маской сигналов, имеющейся на момент запуска программы.

 

10.8. Важные сигналы специального назначения

 

Некоторые сигналы имеют особое назначение. Здесь мы опишем наиболее важные.

 

10.8.1. Сигнальные часы:

sleep()

,

alarm()

и

SIGALARM

 

Часто бывает необходимо написать программу в виде

while (/* некоторое неверное условие */) {

 /* подождать некоторое время */

}

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

until who | grep '^arnold' > /dev/null

do

 sleep 10

done

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

 

10.8.1.1. Труднее, но с большим контролем:

alarm()

и

SIGALARM

Основным строительным блоком является системный вызов alarm():

#include /* POSIX */

unsigned int alarm(unsigned int seconds);

После того, как alarm() возвратится, программа продолжает работать. Однако, когда истекают seconds секунд, ядро посылает процессу SIGALARM. Действием по умолчанию является завершение процесса, но вы скорее всего вместо этого установите обработчик сигнала для SIGALARM.

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

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

 

10.8.1.2. Простой и легкий:

sleep()

Более легкий способ ожидания истечения фиксированного промежутка времени заключается в использовании функции sleep():

#include /* POSIX */

unsigned int sleep(unsigned int seconds);

Возвращаемое значение равно 0, если процесс проспал все отведенное время. В противном случае возвращается оставшееся для сна время. Это последнее значение может возникнуть в случае, если появился сигнал, пока процесс дремал.

ЗАМЕЧАНИЕ . Функция sleep() часто реализуется через сочетание signal() , alarm() и pause() . Такой подход делает опасным смешивание sleep() с вашим собственным вызовом alarm() (или расширенной функцией setitimer() , описанной в разделе 14.3.3 «Интервальные таймеры setitimer() и getitimer() ») Чтобы теперь узнать о функции nanosleep() , см. раздел 14.3.4 «Более точные паузы: nanosleep() ».

 

10.8.2. Сигналы, управляющие заданиями

Несколько сигналов используются для реализации управления заданиями — возможностью начинать и останавливать задания и перемещать их из фонового режима на передний план и обратно. На уровне пользователя вы, несомненно, проделывали это: использовали CTRL-Z для остановки задания, bg для помещения его в фоновый режим, а иногда использовали fg для перемещения фонового или остановленного задания на передний план.

Секция 9.2.1 «Обзор управления заданиями» описывает в общем, как осуществляется управление заданиями. Данный раздел завершает обзор, описав сигналы управления заданиями. поскольку иногда может понадобиться перехватить их непосредственно:

SIGTSTP

Этот сигнал осуществляет «остановку терминала». Это сигнал, который ядро посылает процессу, когда пользователь за терминалом (или окном, эмулирующим терминал) набирает определенный ключ. Обычно это CTRL-Z, аналогично тому, как CTRL-C обычно посылает SIGINT.

Действием по умолчанию для SIGTSTP является остановка (переход в приостановленное состояние) процесса. Однако, вы можете перехватить этот сигнал, как любой другой. Хорошая мысль сделать это, если ваша программа изменяет состояние терминала. Например, рассмотрите экранные редакторы vi или Emacs, которые переводят терминал в посимвольный режим. По получении SIGTSTP, они должны восстановить терминал в его нормальный построчный режим, а затем приостановиться сами.

SIGSTOP

Этот сигнал также останавливает процесс, но он не может быть перехвачен, заблокирован или проигнорирован. Он может быть использован в качестве последнего средства вручную (посредством команды kill) или программным путем. Например, только что обсужденный обработчик SIGTSTP после восстановления состояния терминала мог бы затем использовать для остановки процесса 'raise (SIGSTOP)'.

SIGTTIN, SIGTTOU

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

SIGCONT

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

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

 

10.8.3. Родительский надзор: три различные стратегии

 

Как описано в разделе 9.1.1 «Создание процесса: fork()», одним побочным эффектом вызова fork() является создание между процессами отношений родитель-потомок. Родительский процесс может ждать завершения одного или более из своих потомков и получить статус завершения порожденного процесса посредством одного из семейства системных вызовов wait().

Завершившиеся порожденные процессы, которых никто не ожидал, называются зомби (zombies). Обычно каждый раз при завершении порожденного процесса ядро посылает родительскому процессу сигнал SIGCHLD. Действием по умолчанию является игнорирование этого сигнала. В этом случае процессы зомби накапливаются до тех пор, пока родитель не вызовет wait() или не закончится сам. В последнем случае процессы зомби получают в качестве нового родителя системный процесс init (PID 1), который получает от них результаты как часть своей обычной работы. Сходным образом, активные потомки также получают родителем init, и их результаты будут собраны при их завершении.

SIGCHLD используется для большего, чем уведомление о завершении потомка. Каждый раз при остановке потомка (посредством одного из обсужденных ранее сигналов управления заданиями) родителю также посылается SIGCHLD. Стандарт POSIX указывает, что SIGCHLD «может быть послан» также, когда помок вновь запускается; очевидно, среди оригинальных Unix-систем имеются различия.

Сочетание флагов для поля sa_flags  в struct sigation и использование SIG_IGN в качестве действия для SIGCHLD позволяет изменить способ обработки ядром остановок, возобновления или завершения потомков.

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

 

10.8.3.1. Плохие родители: полное игнорирование потомков

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

Другой возможностью, дающей такой же результат, является использование флага SA_NOCLDWAIТ. В коде:

/* Старый стиль: */        /* Новый стиль: */

signal(SIGCHLD, SIG_IGN);  struct sigaction sa;

                           sa.sa_handler = SIG_IGN;

                           sa.sa_flags = SA_NOCLDWAIT;

                           sigemptyset(&sa.sa_mask);

                           sigaction(SIGCHLD, &sa, NULL);

 

10.8.3.2. Снисходительные родители: минимальный надзор

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

В общем вы не можете ожидать получать по одному сигналу SIGCHLD на каждого завершающегося потомка. Следует считать, что SIGCHLD означает «завершился по крайней мере один потомок» и быть готовым собрать при обработке SIGCHLD сведения о как можно большем числе потомков.

Следующая программа, ch10-reap1.с, блокирует SIGCHLD до тех пор, пока не будет готова восстановить потомков.

1  /* ch10-reap1.с --- демонстрирует управление SIGCHLD с использованием цикла */

2

3  #include

4  #include

5  #include

6  #include

7  #include

8  #include

9

10 #define MAX_KIDS 42

11 #define NOT_USED -1

12

13 pid_t kids[MAX_KIDS];

14 size_t nkids = 0;

Массив потомков отслеживает ID порожденных процессов. Если элемент содержит NOT_USED, он не представляет необработанного потомка. (Его инициализируют строки 89–90 внизу) nkids указывает, сколько значений в kids следует проверить.

16 /* format_num --- вспомогательная функция, поскольку нельзя использовать [sf]printf() */

17

18 const char *format_num(int num)

19 {

20 #define NUMSIZ 30

21  static char buf[NUMSIZ];

22  int i;

23

24  if (num <= 0) {

25   strcpy(buf, "0");

26   return buf;

27  }

28

29  i = NUMSIZ - 1;

30  buf[i--] = '\0';

31

32  /* Преобразует цифры обратно в строку. */

33  do {

34   buf[i--] = (num % 10) + '0';

35   num /= 10;

36  } while (num > 0);

37

38  return &buf[i+1];

39 }

Поскольку обработчики сигналов не должны вызывать функции семейства printf(), мы предусмотрели для преобразования десятичного сигнала или номера PID в строку простую «вспомогательную» функцию format_num(). Это примитивно, но работает.

41 /* childhandler --- перехват SIGCHLD, сбор сведений со всех доступных потомков */

42

43 void childhandler(int sig)

44 {

45  int status, ret;

46  int i;

47  char buf[100];

48  static const char entered[] = "Entered childhandler\n" ;

49  static const char exited[] = "Exited childhandler\n";

50

51  writed, entered, strlen(entered));

52  for (i =0; i < nkids; i++) {

53   if (kids[i] == NOT_USED)

54    continue;

55

56 retry:

57   if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {

58    strcpy(buf, "\treaped process ");

59    strcat(buf, format_num(ret));

60    strcat(buf, "\n");

61    write(1, buf, strlen(buf));

62    kids[i] = NOT_USED;

63   } else if (ret == 0) {

64    strcpy(buf, "\tpid ");

65    strcat(buf, format_num(kids[i]));

66    strcat(buf, " not available yet\n");

67    write(1, buf, strlen(buf));

68   } else if (ret == -1 && errno == EINTR) {

69    write(1, "\tretrying\n", 10);

70    goto retry;

71   } else {

72    strcpy(buf, "\twaitpid() failed: ");

73    strcat(buf, strerror(errno));

74    strcat(buf, "\n");

75    write(1, buf, strlen(buf));

76   }

77  }

78  write(1, exited, strlen(exited));

79 }

Строки 51 и 58 выводят «входное» и «завершающее» сообщения, так что мы можем ясно видеть, когда вызывается обработчик сигнала. Другие сообщения начинаются с ведущего символа TAB.

Главной частью обработчика сигнала является большой цикл, строки 52–77. Строки 53–54 проверяют на NOT_USED и продолжают цикл, если текущий слот не используется.

Строка 57 вызывает waitpid() с PID текущего элемента kids. Мы предусмотрели опцию WNOHANG, которая заставляет waitpid() возвращаться немедленно, если затребованный потомок недоступен. Этот вызов необходим, так как возможно, что не все потомки завершились.

Основываясь на возвращенном значении, код предпринимает соответствующее действие. Строки 57–62 обрабатывают случай обнаружения потомка, выводя сообщение и помещая в соответствующий слот в kids значение NOT_USED.

Строки 63–67 обрабатывают случай, когда затребованный потомок недоступен. В этом случае возвращается значение 0, поэтому выводится сообщение, и выполнение продолжается.

Строки 68–70 обрабатывают случай, при котором был прерван системный вызов. В этом случае самым подходящим способом обработки является goto обратно на вызов waitpid(). (Поскольку main() блокирует все сигналы при вызове обработчика сигнала [строка 96], это прерывание не должно случиться. Но этот пример показывает, как обработать все случаи.)

Строки 71–76 обрабатывают любую другую ошибку, выводя соответствующее сообщение об ошибке.

81  /* main --- установка связанных с порожденными процессами сведений и сигналов, создание порожденных процессов */

82

83  int main(int argc, char **argv)

84  {

85   struct sigaction sa;

86   sigset_t childset, emptyset;

87   int i;

88

89   for (i = 0; i < nkids; i++)

90    kids[i] = NOT_USED;

91

92   sigemptyset(&emptyset);

93

94   sa.sa_flags = SA_NOCLDSTOP;

95   sa.sa_handler = childhandler;

96   sigfillset(&sa.sa_mask); /* блокировать все при вызове обработчика */

97   sigaction(SIGCHLD, &sa, NULL);

98

99   sigemptyset(&childset);

100  sigaddset(&childset, SIGCHLD);

101

102  sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */

103

104  for (nkids = 0; nkids < 5; nkids++) {

105   if ((kids[nkids] = fdrk()) == 0) {

106    sleep(3);

107    _exit(0);

108   }

109  }

110

111  sleep(5); /* дать потомкам возможность завершения */

112

113  printf("waiting for signal\n");

114  sigsuspend(&emptyset);

115

116  return 0;

117 }

Строки 89–90 инициализируют kids. Строка 92 инициализирует emptyset. Строки 94–97 настраивают и устанавливают обработчик сигнала для SIGCHLD. Обратите внимание на использование в строке 94 SA_NOCLDSTOP, тогда как строка 96 блокирует все сигналы при вызове обработчика.

Строки 99–100 создают набор сигналов, представляющих SIGCHLD, а строка 102 устанавливает их в качестве маски сигналов процесса для программы.

Строки 104–109 создают пять порожденных процессов, каждый из которых засыпает на три секунды. По ходу дела они обновляют массив kids и переменную nkids.

Строка 111 дает затем потомкам шанс завершиться, заснув на еще больший промежуток времени. (Это не гарантирует, что порожденные процессы завершатся, но шансы довольно велики.)

Наконец, строки 113–114 выводят сообщение и приостанавливаются, заменив маску сигналов процесса, блокирующую SIGCHLD, пустой маской. Это дает возможность появиться сигналу SIGCHLD, что в свою очередь вызывает запуск обработчика сигнала. Вот что происходит:

$ ch10-reap1 /* Запуск программы */

waiting for signal

Entered childhandler

  reaped process 23937

  reaped process 23938

  reaped process 23939

  reaped process 23940

  reaped process 23941

Exited childhandler

Обработчик сигнала собирает сведения о потомках за один проход.

Следующая программа, ch10-reap2.c, сходна с ch10-reap1.c. Разница в том, что она допускает появление сигнала SIGCHLD в любое время. Такое поведение увеличивает шанс получения более одного SIGCHLD, но не гарантирует это. В результате обработчик сигнала все равно должен быть готов обработать в цикле несколько потомков.

1  /* ch10-reap2.c — демонстрирует управление SIGCHLD, один сигнал на потомка */

2

   /* ...не изменившийся код пропущен... */

12

13 pid_t kids[MAX_KIDS];

14 size_t nkids = 0;

15 size_t kidsleft = 0; /* <<< Добавлено */

16

 /* ...не изменившийся код пропущен... */

41

42 /* childhandler --- перехват SIGCHLD, опрос всех доступных потомков */

43

44 void childhandler(int sig)

45 {

46  int status, ret;

47  int i;

48  char buf[100];

49  static const char entered[] = "Entered childhandler\n";

50  static const char exited[] = "Exited childhandler\n";

51

52  write(1, entered, strlen(entered));

53  for (i = 0; i < nkids; i++) {

54   if (kids[i] == NOT_USED)

55    continue;

56

57 retry:

58  if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {

59   strcpy(buf, "\treaped process ");

60   strcat(buf, format_num(ret));

61   strcat(buf, "\n");

62   write(1, buf, strlen(buf));

63   kids[i] = NOT_USED;

64   kidsleft--; /* <<< Добавлено */

65  } else if (ret == 0) {

    /* ...не изменившийся код пропущен... */

80  write(1, exited, strlen(exited));

81 }

Это идентично предыдущей версии за тем исключением, что у нас есть новая переменная, kidsleft, указывающая, сколько имеется не опрошенных потомков. Строки 15 и 64 помечают новый код.

83  /* main --- установка относящейся к порожденным процессам сведений

       и сигналов, создание порожденных процессов */

84

85  int main(int argc, char **argv)

86  {

     /* ...не изменившийся код пропущен... */

100

101  sigemptyset(&childset);

102  sigaddset(&childset, SIGCHLD);

103

104  /* sigprocmask(SIG_SETMASK, &childset, NULL); /* блокирование в коде main */

105

106  for (nkids = 0; nkids < 5; nkids++) {

107   if ((kids[nkids] = fork()) == 0) {

108    sleep(3);

109    _exit(0);

110   }

111   kidsleft++; /* <<< Added */

112  }

113

114  /* sleep(5); /* дать потомкам шанс завершиться */

115

116  while (kidsleft > 0) { /* <<< Добавлено */

117   printf("waiting for signals\n");

118   sigsuspend(&emptyset);

119  } /* <<< Добавлено */

120

121  return 0;

122 }

Здесь код также почти идентичен. Строки 104 и 114 закомментированы из предыдущей версии, а строки 111, 116 и 119 добавлены. Удивительно, при запуске поведение меняется в зависимости от версии ядра!

$ uname -a /* Отобразить версию системы */

Linux example1 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux

$ ch10-reap2 /* Запустить программу */

waiting for signals

Entered childhandler /* Опрос одного потомка */

  reaped process 2702

  pid 2703 not available yet

  pid 2704 not available yet

  pid 2705 not available yet

  pid 27 06 not available yet

Exited childhandler

waiting for signals

Entered childhandler /* И следующего */

  reaped process 2703

  pid 2704 not available yet

  pid 2705 not available yet

  pid 2706 not available yet

Exited childhandler

waiting for signals

Entered childhandler /* И так далее */

  reaped process 2704

  pid 2705 not available yet

  pid 2706 not available yet

Exited childhandler

waiting for signals

Entered childhandler

  reaped process 2705

  pid 2706 not available yet

Exited childhandler

waiting for signals

Entered childhandler

  reaped process 2706

Exited childhandler

В данном примере на каждый процесс поступает ровно один SIGCHLD! Хотя это прекрасно и полностью воспроизводимо на этой системе, это также необычно. Как на более раннем, так и на более позднем ядре и на Solaris программа получает один сигнал для более чем одного потомка:

$ uname -a /* Отобразить версию системы */

Linux example2 2.4.22-1.2115.npt1 #1 Wed Oct 29 15:42:51 EST 2003 i686 i686 i386 GNU/Linux

$ ch10-reap2 /* Запуск программы */

waiting for signals

Entered childhandler /* Обработчик сигнала вызван лишь однажды */

  reaped process 9564

  reaped process 9565

  reaped process 9566

  reaped process 9567

  reaped process 9568

Exited childhandler

ЗАМЕЧАНИЕ. В коде для ch10-reap2.c есть один важный дефект — состояние гонки. Взгляните еще раз на строки 106–112 в ch10-reap2.c . Что случится, если SIGCHLD появится при исполнении этого кода? Массив kids и переменные nkids и kidsleft могут оказаться разрушенными: код в main добавляет новый процесс, но обработчик сигнала вычитает один.

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

 

10.8.3.3. Строгий родительский контроль

Структура siginfo_t и перехватчик сигнала с тремя аргументами дают возможность узнать, что случилось с потомком. Для SIGCHLD поле si_code структуры siginfo_t указывает причину посылки сигнала (остановка, возобновление, завершение порожденного процесса и т.д.). В табл. 10.5 представлен полный список значений. Все они определены в качестве расширения XSI стандарта POSIX.

Следующая программа, ch10-status.c, демонстрирует использование структуры siginfo_t.

1  /* ch10-status.c --- демонстрирует управление SIGCHLD, используя обработчик с 3 аргументами */

2

3  #include

4  #include

5  #include

6  #include

7  #include

8  #include

9

10 void manage(siginfo_t *si);

11

/* ...не изменившийся для format_num() код опущен... */

Таблица 10.5. Значения si_code XSI для SIGCHLD

Значение Смысл
CLD_CONTINUED Остановленный потомок был возобновлен.
CLD_DUMPED Потомок завершился с ошибкой, создан образ процесса
CLD_EXITED Потомок завершился нормально.
CLD_KILLED Потомок был завершен сигналом
CLD_STOPPED Порожденный процесс был остановлен.
CLD_TRAPPED Трассируемый потомок остановлен (Это условие возникает, когда программа трассируется — либо из отладчика, либо для мониторинга реального времени В любом случае, вы вряд ли увидите его в обычных ситуациях.)

Строки 3–8 включают стандартные заголовочные файлы, строка 10 объявляет manage(), которая имеет дело с изменениями состояния потомка, а функция format_num() не изменилась по сравнению с предыдущим.

37 /* childhandler --- перехват SIGCHLD, сбор данных лишь об одном потомке */

38

39 void childhandler(int sig, siginfo_t *si, void *context)

40 {

41  int status, ret;

42  int i;

43  char buf[100];

44  static const char entered[] = "Entered childhandler\n";

45  static const char exited[] = "Exited childhandler\n";

46

47  write(1, entered, strlen(entered));

48 retry:

49  if ((ret = waitpid(si->si_pid, &status, WNOHANG)) == si->si_pid) {

50   strcpy(buf, "\treaped process ");

51   strcat(buf, format_num(si->si_pid));

52   strcat(buf, "\n");

53   write(1, buf, strlen(buf));

54   manage(si); /* обработать то, что произошло */

55  } else if (ret > 0) {

56   strcpy(buf, "\treaped unexpected pid ");

57   strcat(buf, format_num(ret));

58   strcat(buf, "\n");

59   write(1, buf, strlen(buf));

60   goto retry; /* почему бы нет? */

61  } else if (ret == 0) {

62   strcpy(buf, "\tpid ");

63   strcat(buf, format_num(si->si_pid));

64   strcat(buf, " changed status\n");

65   write(1, buf, strlen(buf));

66   manage(si); /* обработать то, что произошло */

67  } else if (ret == -1 && errno == EINTR) {

68   write(1, "\tretrying\n", 10);

69   goto retry;

70  } else {

71   strcpy(buf, "\twaitpid() failed: ");

72   strcat(buf, strerror(errno));

73   strcat(buf, "\n");

74   write(1, buf, strlen(buf));

75  }

76

77  write(1, exited, strlen(exited));

78 }

Обработчик сигнала похож на показанные ранее. Обратите внимание на список аргументов (строка 39) и на то, что нет цикла.

Строки 49–54 обрабатывают завершение процесса, включая вызов manage() для вывода состояния.

Строки 55–60 обрабатывают случай неожиданного завершения потомка. Этого не должно происходить, поскольку обработчику сигнала передается специфическая для определенного порожденного процесса информация.

Строки 61–66 представляют для нас интерес: возвращаемое значение для изменений состояния равно 0. manage() имеет дело с деталями (строка 66).

Строки 67–69 обрабатывают прерывания, а строки 70–75 распоряжаются ошибками

80 /* child --- что сделать в порожденном процессе */

81

82 void child(void)

83 {

84  raise(SIGCONT); /* должен быть проигнорирован */

85  raise(SIGSTOP); /* заснуть, родитель снова разбудит */

86  printf("\t---> child restarted <---\n");

87  exit(42); /* нормальное завершение, дать возможность родителю получить значение */

88 }

Функция child() обрабатывает поведение порожденного процесса, предпринимая действия для уведомления родителя. Строка 84 посылает SIGCONT, что может вызвать получение родителем события CLD_CONTINUED. Строка 85 посылает SIGSTOP, который останавливает процесс (сигнал не может быть перехвачен) и вызывает для родителя событие CLD_STOPPED. Когда родитель возобновляет порожденный процесс, последний выводит сообщение, что он снова активен, а затем завершается с известным статусом завершения.

90  /* main --- установка относящихся к порожденному процессу сведений

       и сигналов, создание порожденного процесса */

91

92  int main(int argc, char **argv)

93  {

94   pid_t kid;

95   struct sigaction sa;

96   sigset_t childset, emptyset;

97

98   sigemptyset(&emptyset);

99

100  sa.sa_flags = SA_SIGINFO;

101  sa.sa_sigaction = childhandler;

102  sigfillset(&sa.sa_mask); /* при вызове обработчика все заблокировать */

103  sigaction(SIGCHLD, &sa, NULL);

104

105  sigemptyset(&childset);

106  sigaddset(&childset, SIGCHLD);

107

108  sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */

109

110  if ((kid = fork()) == 0)

111   child();

112

113  /* здесь выполняется родитель */

114  for (;;) {

115   printf("waiting for signals\n");

116   sigsuspend(&emptyset);

117  }

118

119  return 0;

120 }

Программа main() все устанавливает. Строки 100–103 помещают на место обработчик. Строка 100 устанавливает флаг SA_SIGINFO таким образом, что используется обработчик с тремя аргументами. Строки 105–108 блокируют SIGCHLD.

Строка 110 создает порожденный процесс. Строки 113–117 продолжаются в родителе, используя для ожидания входящих сигналов sigsuspend().

123 /* manage --- разрешение различных событий, которые могут случиться с потомком */

124

125 void manage(siginfo_t *si)

126 {

127  char buf[100];

128

129  switch (si->si_code) {

130  case CLD_STOPPED:

131   write(1, "\tchild stopped, restarting\n", 27);

132   kill(si->si_pid, SIGCONT);

133   break;

134

135  case CLD_CONTINUED: /* not sent on Linux */

136   write(1, "\tchild continued\n", 17);

137   break;

138

139  case CLD_EXITED:

140   strcpy(buf, "\tchild exited with status ");

141   strcat(buf, format_num(si->si_status));

142   strcat(buf, "\n");

143   write(1, buf, strlen(buf));

144   exit(0); /* we're done */

145   break;

146

147  case CLD_DUMPED:

148   write(1, "\tchild dumped\n", 14);

149   break;

150

151  case CLD_KILLED:

152   write(1, " \tchild killed\n", 14);

153   break;

154

155  case CLD_TRAPPED:

156   write(1, "\tchild trapped\n", 15);

157   break;

158  }

159 }

Посредством функции manage() родитель обрабатывает изменение состояния в порожденном процессе, manage() вызывается, когда изменяется состояние и когда порожденный процесс завершился.

Строки 130–133 обрабатывают случай, когда потомок остановился; родитель возобновляет его, посылая SIGCONT.

Строки 135–137 выводят уведомление о возобновлении потомка. Это событие на системах GNU/Linux не происходит, и стандарт POSIX использует в этом случае невыразительный язык, просто говоря, что это событие может появиться, а не появится.

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

Другие случаи более специализированные. В случае события CLD_KILLED для получения дополнительных сведений было бы полезным значение status, заполненной функцией waitpid().

Вот что происходит при запуске:

$ ch10-status /* Запуск программы */

waiting for signals

Entered childhandler /* Вход в обработчик сигнала */

  pid 24279 changed status

  child stopped, restarting /* Обработчик действует */

Exited childhandler

waiting for signals

  ---> child restarted <--- /* Из потомка */

Entered childhandler

  reaped process 24279 /* Обработчик родителя опрашивает потомка */

  child exited with status 42

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

 

10.9. Сигналы, передающиеся через

fork()

и

exec()

Когда программа вызывает fork(), ситуация с сигналами в порожденном процессе почти идентична ситуации в родительском процессе. Установленные обработчики остаются на месте, заблокированные сигналы остаются заблокированными и т.д. Однако, любые ожидающие в родителе сигналы в потомке сбрасываются, включая установленный с помощью alarm() временной интервал. Это просто, и это имеет смысл.

Когда процесс вызывает одну из функций exec(), положение в новой программе следующее:

• Сигналы с установленным действием по умолчанию остаются с этим действием по умолчанию.

• Все перехваченные сигналы сбрасываются в состояние с действием по умолчанию.

• Сигналы, которые игнорируются, продолжают игнорироваться. Особым случаем является SIGCHLD. Если SIGCHLD до вызова exec() игнорировался, он может игнорироваться также и после вызова. В качестве альтернативы для него может быть восстановлено действие по умолчанию. То, что происходит на самом деле, стандартом POSIX намеренно не определяется. (Справочные страницы GNU/Linux не определяют, что делает Linux, и поскольку POSIX оставляет это не определенным, любой код, который вы пишете для использования SIGCHLD, должен быть подготовлен для обработки любого случая.)

• Сигналы, заблокированные до вызова exec(), остаются заблокированными и после вызова. Другими словами, новая программа наследует маску сигналов существующего процесса.

• Любые ожидающие сигналы (те, которые появились, но были заблокированы) сбрасываются. Новая программа не может их получить.

• Временной интервал, остающийся для alarm(), сохраняется на своем месте. (Другими словами, если процесс устанавливает alarm, а затем непосредственно вызывает exec(), новый образ в конечном счете получит SIGALARM. Если он сначала вызывает fork(), родитель сохраняет установки alarm, тогда как потомок, вызывающий exec(), не сохраняет.

ЗАМЕЧАНИЕ . Многие, если не все. программы предполагают, что сигналы инициализированы действиями по умолчанию и что заблокированных сигналов нет. Таким образом, особенно если не вы писали программу, запускаемую с помощью exec() , можно разблокировать перед вызовам exec() все сигналы

 

10.10. Резюме

• Интерфейсы обработки сигналов развились от простых, но подверженных состояниям гонок, до сложных, но надежных. К сожалению, множественность интерфейсов затрудняет их изучение по сравнению с другими API Linux/Unix.

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

• signal() и raise() стандартизованы ISO С. signal() управляет действиями для определенных сигналов; raise() посылает сигнал текущему процессу. Остаются ли обработчики сигналов установленными после вызова или сбрасываются для действия по умолчанию, зависит от реализации, signal() и raise() являются простейшими интерфейсами, для многих приложений их достаточно.

• POSIX определяет функцию bsd_signal(), которая подобна signal(), но гарантирует, что обработчик остается установленным.

• Действия, происходящие после возвращения из обработчика, варьируют в зависимости от системы. Традиционные системы (V7, Solaris, возможно, и другие) восстанавливают действие сигнала по умолчанию. На этих системах прерванный системный вызов возвращает -1, устанавливая в errno значение EINTR. Системы BSD оставляют обработчик установленным и возвращают -1 с errno, содержащим EINTR, лишь в случае, когда не было перемещения данных; в противном случае, системный вызов запускается повторно.

• GNU/Linux придерживается POSIX, который похож, но не идентичен с BSD. Если не было перемещения данных, системный вызов возвращает -1/EINTR. В противном случае он возвращает объем перемещенных данных. Поведение BSD «всегда повторный запуск» доступно через интерфейс sigaction(), но он не является действием по умолчанию.

• Обработчики сигналов, используемые с signal(), подвержены состояниям гонок. Внутри обработчиков сигналов должны использоваться исключительно переменные типа volatile sig_atomic_t. (В целях упрощения в некоторых из наших примеров мы не всегда следовали этому правилу.) Таким же образом, для вызова из обработчика сигналов безопасными являются лишь функции из табл. 10.2.

• Первоначальной попыткой создания надежных сигналов был API сигналов System V Release 3 (скопированный из BSD 4.0). Не используйте его в новом коде.

• POSIX API содержит множество компонентов:

  • маску сигналов процесса, перечисляющую текущие заблокированные сигналы;

  • тип sigset_t для представления масок сигналов, и функции sigfillset(), sigemptyset(), sigaddset(), sigdelset() и sigismember() для работы с ними;

  • функцию sigprocmask() для установки и получения маски сигналов процесса,

  • функцию sigpending() для получения набора ожидающих сигналов;

  • API sigaction() и struct sigaction во всем их великолепии.

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

• Механизмами POSIX для посылки сигналов являются kill() и killpg(). Они отличаются от raise() в двух отношениях: (1) одни процесс может послать сигнал другому процессу или целой группе процессов (конечно, с проверкой прав доступа), и (2) посылка сигнала 0 ничего не посылает, но осуществляет проверку. Таким образом, эти функции предоставляют способ проверки наличия определенного процесса или группы процессов и возможность посылки ему (им) сигнала.

• Сигналы могут использоваться в качестве механизма IPC, хотя такой способ является плохим способом структурирования приложения, подверженным состояниям гонок. Если кто-то держит приставленным к вашей голове ружье, чтобы заставить вас работать таким способом, для правильной работы используйте тщательное блокирование сигналов и интерфейс sigaction().

• SIGALARM и системный вызов alarm() предоставляют низкоуровневый механизм для уведомления о прошествии определенного числа секунд, pause() приостанавливает процесс, пока не появятся какие-нибудь сигналы, sleep() использует их для помещения процесса в спящее состояние на заданный период времени: sleep() и alarm() не должны использоваться вместе. Сама pause() создает состояние гонки; вместо этого нужно использовать блокирование сигналов и sigsuspend().

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

• Перехват SIGCHLD позволяет родителю узнать, что делает порожденный им процесс. Использование 'signal(SIGCHLD, SIG_IGN)' (или sigaction() с SA_NOCLDWAIT) вообще игнорирует потомков. Использование sigaction() с SA_NOCLDSTOP предоставляет уведомления лишь о завершении. В последнем случае, независимо от того, заблокирован SIGCHLD или нет, обработчики сигналов для SIGCHLD должны быть готовы немедленно обработать несколько потомков. Наконец, использование sigaction() без SA_NOCLDSTOP с обработчиком сигналов с тремя аргументами дает вам причину получения сигнала.

• После fork() положение сигналов в порожденном процессе остается тем же самым, за исключением сброса ожидающих сигналов и установленных интервалов таймера. После exec() положение несколько более сложно — в сущности, все, что может быть оставлено, остается; для всего остального восстанавливаются значения по умолчанию.

 

Упражнения

1. Реализуйте bsd_signal() с использованием sigaction().

2. Если у вас не установлен GNU/Linux, запустите на своей системе ch10-catchint. Является ли ваша система традиционной или BSD?

3. Реализуйте функции System V Release 3 sighold(), sigrelse(), sigignore(), sigpause() и sigset(), использовав sigaction() и другие подходящие функции из POSIX API.

4. Потренируйте свои навыки в жонглировании битами. В предположении, что сигнал 0 отсутствует и что имеется не более 31 сигналов, предусмотрите typedef для sigset_t и напишите sigemptyset(), sigfillset(), sigaddset(), sigdelset() и sigismember().

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

6. Теперь, когда вы сделали предыдущие два упражнения, найдите sigemptyset() и др. в своем заголовочном файле . (Может потребоваться поискать их; они могут быть в #include файлах, указанных в .) Являются ли они макросами или функциями?

7. В разделе 10.7 «Сигналы для межпроцессного взаимодействия» мы упомянули, что код изделия должен работать с начальной маской сигналов процесса, добавляя и удаляя блокируемые сигналы в вызове sigsuspend(). Перепишите пример, используя для этого соответствующие вызовы.

8. Напишите свою собственную версию команды kill. Интерфейс должен быть таким:

kill [-s имя-сигнала ] pid ...

Если сигнал не указан, программа должна посылать SIGTERM.

9. Как вы думаете, почему в современных оболочках, таких, как Bash и ksh93, kill является встроенной командой?

10. (Трудное) Реализуйте sleep(), используя alarm(), signal() и pause(). Что случится, если обработчик сигнала для SIGALRM уже установлен?

11. Поэкспериментируйте с ch10-reap.c, изменяя интервал времени, на который засыпает каждый потомок, и организуя достаточное число вызовов sigsuspend() для сбора сведений о всех потомках.

12. Попробуйте заставить ch10-reap2.c испортить информацию в kids, nkids и kidsleft. Теперь добавьте вокруг критического раздела блокирование/разблокирование и посмотрите, есть ли разница.

 

Глава 11

Права доступа и ID пользователей и групп

 

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

 

11.1. Проверка прав доступа

 

Как мы видели в разделе 5.4.2 «Получение информации о файлах», файловая система хранит идентификаторы владельца и группы файла в виде числовых значений; это типы uid_t и gid_t соответственно. Для краткости мы используем для «идентификатора владельца (пользователя)» и «идентификатора группы» сокращения UID и GID соответственно.

У каждого процесса есть несколько связанных с ним идентификаторов пользователя и группы. Для проверки прав доступа в качестве упрощения используется один определенный UID и GID; когда UID процесса совпадает с UID файла, биты прав доступа пользователя файла диктуют, что может сделать процесс с файлом. Если они не совпадают, система проверяет GID процесса с GID файла; при совпадении используются права доступа группы; в противном случае, используются права доступа для «остальных».

Помимо файлов, UID определяет, как один процесс может повлиять на другой путем посылки сигналов. Сигналы описаны в главе 10 «Сигналы».

Наконец, особым случаем является суперпользователь, root. root идентифицируется по UID, равным 0. Когда у процесса UID равен 0, ядро позволяет ему делать все, что он захочет: читать, записывать или удалять файлы, посылать сигналы произвольным процессам и т.д. (POSIX в этом отношении более непонятный, ссылаясь на процессы с «соответствующими привилегиями». Этот язык, в свою очередь, просочился в справочные страницы GNU/Linux и справочное руководство GLIBC online Info manual. Некоторые операционные системы действительно разделяют привилегии пользователей, и Linux также движется в этом направлении. Тем не менее, в настоящее время «соответствующие привилегии» означает просто процессы с UID, равным 0.)

 

11.1.1. Действительные и эффективные ID

Номера UID и GID подобны персональным удостоверениям личности. Иногда вам может понадобиться более одного удостоверяющего документа. Например, у вас могут быть водительские права или правительственное удостоверение личности. Вдобавок, ваш университет или компания могли выдать вам свои удостоверения личности. То же самое относится и к процессам; они имеют при себе множество следующих номеров UID и GID:

Действительный ID пользователя

UID пользователя, породившего процесс.

Эффективный ID пользователя

UID, использующийся при большинстве проверок прав доступа. В большинстве случаев эффективный и действительный UID являются одним и тем же. Эффективный UID может отличаться от действительного при запуске, если установлен бит setuid файла исполняемой программы и файл не принадлежит пользователю, запускающему программу. (Вскоре будут дополнительные сведения.)

Сохраненный set-user ID

Первоначальный эффективный UID при запуске программы (после выполнения exec.) Имеет значение при проверке прав доступа, когда процессу нужно менять действительный и эффективный UID в ходе работы. Эта концепция пришла из System V.

Действительный ID группы

GID пользователя, создавшего процесс, аналогично действительному UID.

Эффективный ID группы

GID, использующийся для проверки прав доступа, аналогично эффективному GID.

Сохраненный set-group ID

Первоначальный эффективный GID при запуске программы, аналогично сохраненному set-user ID.

Набор дополнительных групп

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

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

 

11.1.2. Биты Setuid и Setgid

Биты setuid и setgid в правах доступа к файлу заставляют процесс принять эффективный UID или GID, который отличается от действительного. Эти биты накладываются на файл вручную с помощью команды chmod:

$ chmod u+s myprogram /* Добавить бит setuid */

$ chmod g+s myprogram /* Добавить бит setgid */

$ ls -l myprogram

-rwsr-sr-x 1 arnold devel 4573 Oct 9 18:17 myprogram

Наличие символа s в месте, где обычно находится символ x, указывает на присутствие битов setuid/setgid.

Как упоминалось в разделе 8.2.1 «Использование опций монтирования», опция nosuid команды mount для файловой системы предотвращает обращение ядра к битам setuid и setgid. Это мера безопасности; например, пользователь с домашней системой GNU/Linux мог бы вручную изготовить гибкий диск с копией исполняемого файла оболочки с setuid, устанавливающей в root. Но если система GNU/Linux в офисе или лаборатории монтирует файловые системы с гибкими дисками с опцией nosuid, запуск этой оболочки не предоставит доступа с правами root.

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

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

Однако, заставив программу устанавливать setuid на вас, пользователи, запускающие игру, получат ваш UID в качестве своего эффективного UID. Игровая программа сможет при этом открывать и обновлять файл счета по мере необходимости, но произвольные пользователи не смогут прийти и отредактировать его. (Вы подвергаете себя также большинству опасностей при программировании setuid; например, если в игровой программе есть дыра, которую можно использовать для запуска оболочки, действующей от вашего имени, все ваши файлы оказываются доступными для удаления или изменения. Это действительно устрашающая мысль.)

Та же логика применяется к программам setgid, хотя на практике программы с setgid используются гораздо реже, чем с setuid (Это также плохо; многие вещи, которые делаются программами с setuid root, легко могут быть сделаны программами с setgid или программами, которые вместо этого устанавливают setuid на обычного пользователя).

 

11.2. Получение ID пользователя и группы

Получение от системы сведений о UID и GID просто. Функции следующие:

#include /* POSIX */

uid_t getuid(void); /* Действительный и эффективный UID */

uid_t geteuid(void);

gid_t getgid(void); /* Действительный и эффективный GID */

gid_t getegid(void);

int getgroups(int size, gid_t list[]); /* Список дополнительных групп*/

Функции:

uid_t getuid(void)

Возвращает действительный UID.

uid_t geteuid(void)

Возвращает эффективный UID.

gid_t getgid(void)

Возвращает действительный GID.

gid_t getegid(void)

Возвращает эффективный GID.

int getgroups(int size, gid_t list[])

Заполняет до size элементов массива list из набора дополнительных групп процесса. Возвращаемое значение является числом заполненных элементов или -1 при ошибке. Включается ли в набор также эффективный GID, зависит от реализации. На системах, совместимых с POSIX, можно передать в size нулевое значение; в этом случае getgroups() возвращает число групп в наборе групп процесса. Затем можно использовать это значение для динамического выделения массива достаточного размера. На не-POSIX системах константа NGROUPS_MAX определяет максимально допустимый размер для массива list. Эту константу можно найти в современных системах в , а в старых системах в . Вскоре мы представим пример.

Возможно, вы заметили, что для получения сохраненных значений set-user ID или set-group ID нет вызовов. Это просто первоначальные значения эффективных UID и GID. Таким образом, для получения шести значений в начале программы вы можете использовать код наподобие этого:

uid_t ruid, euid, saved_uid;

gid_t rgid, egid, saved_gid;

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

 ruid = getuid();

 euid = saved_uid = geteuid();

 rgid = getgid();

 egid = saved_gid = getegid();

 /* ...оставшаяся программа... */

}

Вот пример получения набора групп. В качестве расширения gawk предоставляет доступ на уровне awk к значениям действительных и эффективных UID и GID и дополнительному набору групп. Для этого он должен получить набор групп. Следующая функция из main.c в дистрибутиве gawk 3.1.3:

1080 /* init_groupset --- инициализация набора групп */

1081

1082 static void

1083 init_groupset()

1084 {

1085 #if defined(HAVE_GETGROUPS) && defined(NGROUPS_MAX) && NGROUPS_MAX > 0

1086 #ifdef GETGROUPS_NOT_STANDARD

1087  /* Для систем, которые не отвечают стандарту, используйте старый способ */

1088  ngroups = NGROUPS_MAX;

1089 #else

1090  /*

1091   * Если оба аргумента при вызове равны 0, возвращаемое

1092   * значение является общим числом групп.

1093   */

1094  ngroups = getgroups(0, NULL);

1095 #endif

1096  if (ngroups == -1)

1097   fatal(_("could not find groups: %s"), strerror(errno));

1098  else if (ngroups == 0)

1099   return;

1100

1101  /* заполнить группы */

1102  emalloc(groupset, GETGROUPS_T*, ngroups * sizeof(GETGROUPS_T), "init_groupset");

1103

1104  ngroups = getgroups(ngroups, groupset);

1105  if (ngroups == -1)

1106   fatal(_("could not find groups: %s"), strerror(errno));

1107 #endif

1108 }

Переменные ngroups и groupset глобальные; их объявления не показаны. Макрос GETGROUPS_T (строка 1102) является типом для использования со вторым аргументом: на системе POSIX это gid_t, в противном случае int.

Строки 1085 и 1107 заключают в скобки все тело функции; на древних системах, в которых вообще нет наборов групп, тело функции пустое.

Строки 1086–1088 обрабатывают не-POSIX системы; до компиляции программы механизмом конфигурации определяется GETGROUPS_NOT_STANDARD. В этом случае код использует NGROUPS_MAX, как описано выше. (Даже а 2004 г. такие системы все еще существуют и используются; хотя, слава богу, число их уменьшается.)

Строки 1089–1094 для систем POSIX, причем нулевой параметр size используется для получения числа групп.

Строки 1096–1099 осуществляют проверку ошибок. Если возвращаемое значение 0, дополнительных групп нет, поэтому init_groupset() просто сразу возвращается.

Наконец, строка 1102 для выделения массива достаточного размера использует malloc() (посредством проверяющего ошибки макроса-оболочки, см. раздел 3.2.1.8 «Пример: чтение строк произвольной длины»). Затем строка 1104 заполняет этот массив.

 

11.3. Проверка для действительного пользователя:

access()

В большинстве случаев значения эффективного и действительного UID и GID являются одними и теми же. Таким образом, не имеет значения, что проверка прав доступа к файлу осуществляется по эффективному ID, а не по действительному.

Однако, при написании приложения с setuid или setgid вы можете иногда захотеть проверить, является ли операция, разрешенная для эффективных UID и GID, также разрешенной для действительных UID и GID. В этом заключается задача функции access():

#include /* POSIX */

int access(const char *path, int amode);

Аргумент path является путем к файлу для проверки действительных UID и GID. amode содержит объединение побитовым ИЛИ одного или нескольких из следующих значений:

R_OK  Действительный UID/GID разрешает чтение файла.

W_OK  Действительный UID/GID разрешает запись в файл.

X_OK  Действительный UID/GID разрешает исполнение файла или, в случае каталога, поиск в каталоге.

F_OK  Проверка существования файла.

Проверяется каждый компонент в имени пути, а на некоторых реализациях при проверке для root access() может действовать, как если бы был установлен X_OK, даже если в правах доступа к файлу не установлены биты, разрешающие исполнение. (Странно, но верно: в этом случае предупрежденный вооружен.) В Linux нет такой проблемы.

Если path является символической ссылкой, access() проверяет файл, на который указывает символическая ссылка.

Возвращаемое значение равно 0, если операция для действительных UID и GID разрешена, и -1 в противном случае. Соответственно, если access() возвращает -1, программа с setuid может запретить доступ к файлу, с которым в противном случае эффективный UID/GID смог бы работать:

if (access("/some/special/file", R_OK|W_OK) < 0) {

 fprintf(stderr, "Sorry: /some/special/file: %s\n",

  strerror(errno));

 exit(1);

}

По крайней мере для серии ядра Linux 2.4, когда тест X_OK применяется к файловой системе, смонтированной с опцией noexec (см. раздел 8.2.1 «Использование опций монтирования»), тест успешно проходится, если права доступа к файлу имеют разрешение на исполнение. Это верно, несмотря на то, что попытка выполнить файл завершилась бы неудачей.

ЗАМЕЧАНИЕ . Хотя использование access() перед открытием файла является обычной практикой, существует состояние гонки открываемый файл может быть сброшен при подкачке между проверкой функцией access() и вызовом open() . Необходимо осмотрительное программирование, такое, как проверка владельца и прав доступа с помощью stat() и fstat() до и после вызовов access() и open() .

Например, программа pathchk проверяет действительность имен путей. GNU версия использует access() для проверки того, что компоненты каталога данного пути действительны. Из Coreutils pathchk.c:

244 /* Возвращает 1, если PATH является годным к использованию

245    каталогом, 0 если нет, 2 если он не существует. */

246

247 static int

248 dir_ok(const char *path)

249 {

250  struct stat stats;

251

252  if (stat (path, &stats)) /* Nonzero return = failure */

253   return 2;

254

255  if (!S_ISDIR(stats.st_mode))

256  {

257   error(0, 0, _("'%s" is not a directory"), path);

258   return 0;

259  }

260

261  /* Используйте access для проверки прав доступа на поиск,

262     поскольку при проверке битов прав доступа st_mode они могут

263     потеряться новыми механизмами управления доступом. Конечно,

264     доступ теряется, если вы используете setuid. */

265  if (access (path, X_OK) != 0)

266  {

267   if (errno == EACCES)

268    error (0, 0, _("directory '%s' is not searchable"), path);

269   else

270    error(0, errno, "%s", path);

271   return 0;

272  }

273

274  return 1;

275 }

Код прост. Строки 252–253 проверяют, существует ли файл. Если stat() завершится неудачей, файл не существует. Строки 255–259 удостоверяют, что файл в самом деле является каталогом.

Комментарий в строках 261–264 объясняет использование access(). Проверки битов st_mode недостаточно: файл может находиться в файловой системе, которая смонтирована только для чтения, в удаленной файловой системе или в файловой системе, не принадлежащей Linux или Unix, или у файла могут быть атрибуты, предотвращающие доступ. Таким образом, лишь ядро может в действительности сказать, будет ли работать access. Строки 265–272 осуществляют проверку, выдавая сообщение об ошибке, определяемое значением errno (строки 267–270).

 

11.4. Проверка для эффективного пользователя:

euidaccess()

(GLIBC)

GLIBC предоставляет дополнительную функцию, которая работает подобно access(), но проверяет в соответствии с эффективными UID, GID и набором групп:

#include /* CLIBC */

int euidaccess(const char *path, int amode);

Аргументы и возвращаемое значение имеют тот же смысл, как для access(). Когда равны эффективный и действительный UID и эффективный и действительный GID, euidaccess() вызывает для осуществления теста access(). Это имеет то преимущество, что ядро может проверить файловую систему только для чтения или другие условия, которые не отражаются в правах доступа и владении файлами.

В противном случае euidaccess() сравнивает значения владельца и группы файла со значениями эффективных UID и GID и набора групп, используя соответствующие биты прав доступа. Этот тест основан на сведениях о файле от stat().

Если вы пишете переносимую программу, но предпочитаете использовать этот интерфейс, достаточно просто извлечь исходный файл из архива GLIBC и приспособить его для общего использования.

 

11.5. Установка дополнительных битов доступа для каталогов

 

На современных системах setgid и «липкий» биты имеют особое значение при применении к каталогам.

 

11.5.1. Группа по умолчанию для новых файлов и каталогов

В оригинальной системе Unix, когда open() или creat() создавали новый файл, он получал эффективные UID и GID создавшего их процесса.

V7, BSD вплоть до BSD 4.1 и System V вплоть до Release 3 все трактовали каталоги как файлы. Однако, с добавлением дополнительного набора групп в BSD 4.2 способ создания новых каталогов изменился: новые каталоги наследовали группу родительского каталога. Более того, новые файлы также наследовали ID группы родительского каталога, а не эффективный GID создающего процесса.

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

Что происходит на современных системах? Ну, это еще один из немногих случаев, когда можно поймать двух зайцев. SunOS 4.0 придумал механизм, который был включен в System V Release 4; сегодня он используется по крайней мере в Solaris и GNU/Linux. Эти системы придают биту setgid родительского каталога нового файла или каталога следующее значение:

Бит setgid родительского каталога сброшен

Новые файлы и каталоги получают эффективный GID создающего процесса.

Бит setgid родительского каталога установлен

Новые файлы и каталоги получают GID родительского каталога. Новые каталоги наследуют также установленный бит setgid.

(До SunOS 4.0 бит setgid для каталогов не имел определенного значения.) Следующий сеанс показывает бит setgid в действии:

$ cd /tmp /* Перейти в /tmp */

$ ls -ld . /* Проверить его права доступа */

drwxrwxrwt 8 root root 4096 Oct 16 17:40 .

$ id /* Отметить текущие группы */

uid=2076(arnold) gid=42(devel) groups=19(floppy),42(devel),2076(arnold)

$ mkdir d1 ; ls -ld d1 /* Создать новый каталог */

drwxr-xr-x 2 arnold devel 4096 Oct 16 17:40 d1 /* Эффективный ID группы

                                                  наследуется */

$ chgrp arnold d1 /* Сменить группу */

$ chmod g+s d1 /* Добавить бит setgid */

$ ls -ld d1 /* Проверить изменение */

drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:40 d1

$ cd d1 /* Перейти в него */

$ echo this should have group arnold on it > f1 /* создать новый файл */

$ ls -l f1 /* Проверить права доступа */

-rw-r--r-- 1 arnold arnold 36 Oct 16 17:41 f1

 /* Унаследовано от родителя */

$ mkdir d2 /* Создать каталог */

$ ls -ld d2 /* Проверить права доступа */

drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:51 d2

 /* Группа и setgid унаследованы */

Файловые системы ext2 и ext3 для GNU/Linux работают указанным способом. Вдобавок они поддерживают специальные опции монтирования grpid и bsdgroups, которые делают «использование группы родительского каталога» семантикой по умолчанию. (Два имени означают одно и то же.) Другими словами, когда используются эти опции монтирования, в родительских каталогах не нужно устанавливать свои биты seigid.

Противоположными опциями монтирования являются nogrpid и sysvgroups. Это поведение по умолчанию; однако, бит setgid. если он есть, все равно учитывается. (Здесь также оба имени означают одно и то же.)

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

 

11.5.2. Каталоги и «липкий» бит

«Липкий» бит ведет начало от версий Unix для PDP-11, он использовался с обычными исполняемыми файлами. Этот бит использовался с программами, которые предназначались для интенсивного использования, такими, как оболочка и редактор. Когда у программы был установлен этот бит, ядро хранило копию исполняемого кода программы на устройстве подкачки, из которого ее можно было быстро загрузить в память для повторного использования. (Загрузка из файловой системы занимает больше времени образ на устройстве подкачки хранился в смежных дисковых блоках, тогда как образ в файловой системе мог быть разбросан по всему диску). Исполняемые образы были «приклеены» к устройству подкачки, отсюда и название.

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

В современных системах значительно более быстрые дисковое оборудование и память, чем в давнишней PDP-11. Они используют также методику, называемую подкачка по требованию, для загрузки в память лишь тех частей исполняемой программы, которые выполняются. Таким образом, сегодня «липкий» бит обычных исполняемых файлов не служит никаким целям и на самом деле ни на что не влияет.

Однако, в разделе 1.1.2 «Каталоги и имена файлов» мы упомянули, что «липкий» бит в каталоге, запись в который в других отношениях разрешена, предотвращает удаление файлов из этого каталога и их переименование любым пользователем, кроме владельца файла или root. Вот пример:

$ ls -ld /tmp /* Показать права доступа к /tmp */

drwxrwxrwt 19 root root 4096 Oct 20 14:04 /tmp

$ cd /tmp /* Перейти туда */

$ echo this is my file > arnolds-file /* Создать файл */

$ ls -l arnolds-file /* Показать его права доступа */

-rw-r--r-- 1 arnold devel 16 Oct 20 14:14 arnolds-file

$ su - miriam /* Смена пользователя */

Password:

$ cd /tmp /* Перейти в /tmp */

$ rm arnolds-file /* Попытка удаления файла */

rm: remove write-protected regular file 'arnolds-file'? y

 /* rm предупреждает */

rm: cannot remove 'arnolds-file': Operation not permitted

 /* Ядро запрещает удаление */

Основным назначением этой особенности является как раз использование в таких каталогах, как /tmp, куда хотят помещать свои файлы множество пользователей. С одной стороны, каталог должен иметь права записи для всех, чтобы каждый мог создавать там свои файлы. С другой стороны, раз запись разрешена для всех, любой пользователь может удалять файлы всех остальных пользователей! «Липкий» бит каталога красиво решает эту проблему. Для добавления к файлу или каталогу «липкого» бита используйте 'chmod +t':

$ mkdir mytmp /* Создать каталог */

$ chmod a+wxt mytmp /* Добавить права записи для всех и «липкий» бит */

$ ls -ld mytmp /* Проверить результат */

drwxrwxrwt 2 arnold devel 4096 Oct 20 14:23 mytmp

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

 

11.6. Установка действительных и эффективных ID

 

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

 

11.6.1. Изменение набора групп

Функция setgroups() устанавливает новый набор групп:

#include /* Common */

#include

#include

int setgroups(size_t size, const gid_t *list);

Параметр size указывает, сколько элементов в массиве list. Возвращаемое значение равно 0, если все было нормально, и -1 с установленным errno в противном случае.

В отличие от функций для манипулирования значениями действительных и эффективных UID и GID, эту функцию может вызвать лишь процесс, действующий как root. Это один пример того, что POSIX называет привилегированной операцией; сама она как таковая не стандартизуется POSIX.

setgroups() используется любой программой, которая осуществляет регистрацию в системе, такой как /bin/login для регистрации в консоли и /bin/sshd для удаленной регистрации с помощью ssh.

 

11.6.2. Изменение действительного и эффективного ID

Работа с двумя различными ID пользователей представляет для программиста приложения проблему. Могут быть вещи, которые программе нужно сделать, работая с эффективным UID, а другие вещи — работая с действительным UID.

Например, до того, как в системах Unix появилось управление заданиями, многие программы предоставляли переходы в оболочку, т.е. способ запуска команды или интерактивной оболочки из текущей программы. Хорошим примером этого является редактор ed: набор командной строки, начинающейся с '!', запускает оставшуюся часть строки в качестве команды оболочки. Набрав '!sh', вы получаете интерактивную оболочку. (Это работает до сих пор — попробуйте!) Предположим, описанная ранее гипотетическая игровая программа также предоставляет переход в оболочку: она должна быть запущена от имени действительного пользователя, а не эффективного. В противном случае, редактирование файла счета или многие гораздо худшие вещи становятся для игрока тривиальной задачей!

Таким образом, имеется явная потребность в возможности замены эффективного UID действительным UID. Более того, полезна возможность обратного переключения эффективного UID на первоначальный. (В этом причина необходимости наличия сохраненного set-user ID; появляется возможность восстановления первоначальных привилегий, которые были у процесса при его запуске.)

Как и для множества Unix API, различные системы решили проблему разными способами, иногда с использованием одного и того же API, но с другой семантикой, а иногда введением другого API. Погружение в исторические подробности годится лишь для создания головной боли, поэтому мы не будем с этим беспокоиться. Вместо этого мы рассмотрим, что предоставляет POSIX и как работает каждый API. Более того, наше обсуждение фокусируется на значениях действительных и эффективных UID; значения GID работают аналогичным образом, поэтому мы не будем хлопотать с повторением подробностей для этих системных вызовов. Функции следующие:

#include /* POSIX */

#include

int seteuid(uid_t euid); /* Установка эффективного ID */

int setegid(gid_t egid);

int setuid(uid_t uid);

 /* Установка эффективного ID, root устанавливает все */

int setgid(gid_t gid);

int setreuid(uid_t ruid, uid_t euid);

 /* Совместимость с BSD, устанавливаются оба */

int setregid(gid_t rgid, gid_t egid);

Есть три набора функций. Первые два были созданы POSIX:

int seteuid(uid_t euid)

Эта функция устанавливает лишь эффективный UID. Обычный пользователь (не root) может установить в качестве ID лишь в значения действительного, эффективного или сохраненного set-user ID. Приложения, которые будут переключать эффективный UID. должны использовать исключительно эту функцию.

Процесс с эффективным UID, равным нулю, может установить в качестве эффективного UID любое значение. Поскольку в качестве значения эффективного UID можно установить также сохраненный set-user ID, процесс может восстановить свои привилегии root с помощью другого вызова seteuid().

int setegid(gid_t egid)

Эта функция делает для эффективного ID группы то, что seteuid() делает для эффективного ID пользователя.

Следующий набор функций предлагает первоначальный API Unix для изменения действительных и эффективных UID и GID. В модели POSIX эти функции являются тем. что должна использовать программа с setuid-root для постоянного изменения действительного или эффективного UID:

int setuid(uid_t uid)

Для обычного пользователя эта функция также устанавливает лишь эффективный UID. Как и для seteuid(), значением эффективного UID может быть любое из текущих значений действительного, эффективного иди сохраненного set-user ID. Изменение не постоянно; эффективный UID может быть изменен последующим вызовом на другое значение (из того же исходного набора).

Однако, для root эта функция устанавливает в данное значение все три значения для действительного, эффективного и сохраненного set-user ID. Более того, изменение постоянно; прежнее ID нельзя восстановить. (Это имеет смысл: раз изменился сохраненный set-user ID, нет другого ID для восстановления.)

int setgid(gid_t gid)

Эта функция делает для эффективного ID группы то же, что setuid() делает для эффективного ID пользователя. Используется то же разграничение между обычными пользователями и root.

ЗАМЕЧАНИЕ . Возможность изменения ID группы зависит от эффективного ID пользователя. Эффективный GID, равный 0, не имеет особых привилегий.

Наконец, POSIX представляет для исторической совместимости две функции из BSD 4.2. В новом коде их лучше не использовать. Однако, поскольку вы, вероятно, увидите использующий эти функции старый код, мы их здесь опишем.

int setreuid(uid_t ruid, uid_t euid)

Устанавливает данные значения в качестве действительного и эффективного UID. Значение -1 для ruid или euid оставляет соответствующие ID без изменения. (Это похоже на chown(); см. раздел 5.5.1 «Смена владельца файла: chown(), fchown() и lchown()».)

root может устанавливать в качестве действительного и эффективного ID любое значение. В соответствии с POSIX пользователи, не являющиеся root, могут изменять лишь эффективный ID; то, что случится, если обычный пользователь попытается изменить действительный UID, «не определено». Однако, справочная страница GNU/Linux setreuid(2) разъясняет поведение Linux, в качестве действительного UID может быть установлено значение действительного или эффективного UID, а в качестве эффективного UID может быть значение действительного, эффективного или сохраненного set-user ID. (Для других систем см. справочную страницу setreuid(2).)

int setregid(gid_t rgid, gid_t egid)

Делает для действительных и эффективных ID групп то же, что setreuid() делает для действительных и эффективных ID пользователя. Используется то же разграничение между обычными пользователями и root.

Сохраненный set-user ID в модели BSD не существует, поэтому лежащей в основе setreuid() и setregid() идеей было упростить переключение между действительным и эффективным ID:

setreuid(geteuid(), getuid()); /* обмен действительным и эффективным */

Однако, с принятием POSIX модели сохранения set-user ID и функций seteuid() и setegid() функции BSD не следует использовать в новом коде. Даже документация BSD 4.4 помечает эти функции как устаревшие, рекомендуя вместо них seteuid()/setuid() и setegid()/setgid().

 

11.6.3. Использование битов setuid и setgid

Есть важные случаи, в которых действующая как root программа должна безвозвратно изменить все три значения действительного, эффективного и сохраненного set-user ID на ID обычного пользователя. Наиболее очевидным случаем является программа login, которую вы используете (либо непосредственно, либо удаленно) каждый раз при регистрации в системе GNU/Linux или Unix. Имеется иерархия программ, как очерчено на рис. 11.1.

Рис. 11.1. От init через getty через login к shell

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

1. init является самым первым процессом. Его PID равен 1. Все другие процессы являются его потомками. Ядро вручную создает процесс 1 во время загрузки и запускает в нем init. Он действует с действительным и эффективным UID, равными нулю, т.е. как root.

2. init читает /etc/inittab, который, помимо прочих вещей, сообщает init о том, на каких устройствах он должен запустить процесс getty. Для каждого такого устройства (такого, как консоль, последовательные терминалы или виртуальные консоли в системе GNU/Linux) init порождает новый процесс. Этот новый процесс использует затем exec() для запуска getty (от «get tty» («получить tty», т.е. терминал)). На многих системах GNU/Linux эта команда называется mingetty. Программа открывает устройство, сбрасывает его состояние и выводит приглашение 'login:'.

3. По получении регистрационного имени getty выполняет login. Программа login ищет имя пользователя в файле паролей, запрашивает пароль и проверяет его. Если пароль подходит, процесс login продолжается.

4. login изменяет домашний каталог пользователя, устанавливает начальное окружение, а затем устанавливает начальный набор открытых файлов. Он закрывает дескрипторы файлов, открывает терминал и использует dup() для копирования дескрипторов файла терминала в 0, 1 и 2. Вот откуда происходят дескрипторы уже открытых файлов стандартного ввода, стандартного вывода и стандартной ошибки.

5. Затем login использует setgroups() для установки дополнительного набора групп, setgid() для установки значений действительного, эффективного и сохраненного set-group ID в соответствующее значение группы пользователя, и наконец, setuid() для установки всех трех значений действительного, эффективного и сохраненного set-user ID в соответствующие значения для регистрирующегося пользователя. Обратите внимание, что вызов setuid() должен быть последним для того, чтобы другие два вызова завершились успешно.

6. Наконец, login вызывает зарегистрированную оболочку пользователя. Оболочки в стиле Борна после этого читают файлы /etc/profile и $HOME/.profile, если они существуют. Затем оболочка выводит приглашение.

Обратите внимание, как один процесс меняет свою сущность от системного процесса до процесса пользователя. Каждый потомок init начинается как копия init. Используя exec(), тот же самый процесс выполняет различные задания. Вызвав setuid() для перехода от root к обычному пользователю, процесс в конечном счете поступает непосредственно для работы пользователя. Когда вы выходите из оболочки (посредством CTRL-D или exit), процесс попросту завершается. Затем init возобновляет цикл, порождая новый getty, который выводит новое приглашение 'login:'.

ЗАМЕЧАНИЕ . Открытые файлы остаются открытыми и доступными для использования, даже после изменения процессом своих UID или GID. Таким образом, программы с setuid должны заранее открыть все нужные файлы, изменить их ID на ID действительного пользователя и продолжить оставшуюся часть работы без дополнительных привилегий

В табл. 11.1 приведена сводка шести стандартных функций для манипулирования значениями UID и GID.

Таблица 11.1. Сводка API для установки действительных и эффективных ID

Функция Устанавливает Постоянно Обычный пользователь Root
seteuid() E Нет Из R, E, S Любое
setegid() E Нет Из R, E, S Любое
setuid() Root: R,E,S Другие: E Root: да Другие: нет Из R, E Любое
setgid() Root: R,E,S Другие: E Root: да Другие: нет Из R, E Любое
setreuid() E, может установить R Нет Из R, E Любое
setregid() E, может установить R Нет Из R, E Любое

 

11.7. Работа со всеми тремя ID:

getresuid()

и

setresuid()

(Linux)

Linux предоставляет дополнительные системные вызовы, посредством которых вы можете непосредственно работать с действительными, эффективными и сохраненными ID пользователя и группы:

#include /* Linux */

#include

int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);

int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid);

int setresuid(uid_t ruid, uid_t euid, uid_t suid);

int setresgid(gid_t rgid, gid_t egid, gid_t sgid);

Функции следующие:

int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid)

Получает значения действительного, эффективного и сохраненного set-user ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке, errno указывает проблему.

int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid)

Получает значения действительного, эффективного и сохраненного set-group ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке, errno обозначает проблему.

int setresuid(uid_t ruid, uid_t euid, uid_t suid)

Устанавливает значения действительного, эффективного и сохраненного set-user ID соответственно. Когда значение параметра равно -1, соответствующий UID остается без изменения.

Когда процесс действует как root, параметрами могут быть любые произвольные значения. Однако, использование ненулевого значения для euid вызывает постоянную, безвозвратную утерю привилегии root). В противном случае параметры должны быть одним из значений действительного, эффективного или сохраненного set-user ID.

int setresgid(gid_t rgid, gid_t egid, gid_t sgid)

Устанавливает значения действительного, эффективного и сохраненного set-group ID соответственно. Когда значение параметра равно -1, соответствующий GID остается без изменений.

Эта функция аналогична setresuid().

Функции setresuid() и setresgid() особенно ценны, поскольку их семантика ясно определена. Программист точно знает, каким может быть результат их вызова.

Более того, вызовы являются операциями типа «все или ничего»: они либо полностью успешны в осуществлении нужного изменения, либо терпят полную неудачу, оставляя текущее состояние как есть. Это повышает надежность, поскольку, опять-таки можно быть точно уверенным в том, что случилось.

 

11.8. Пересечение минного поля безопасности: setuid

root

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

Точно также написание программ, которые используют setuid root, является трудной задачей. Имеется много, очень много проблем, о которых нужно знать, и почти все может иметь неожиданные последствия в плане безопасности. Такая попытка должна предприниматься очень осторожно.

В частности, стоит специально изучить проблемы безопасности Linux/Unix и потратить время на обучение написанию программ setuid root. Если вы сразу нырнете в эту проблему, прочитав лишь эту книгу и ничего более, можно быть уверенным, что ваша система будет взломана, легко и сразу. Маловероятно, что вы или ваши клиенты будут довольны.

Вот несколько руководящих принципов:

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

• Соответствующим образом проектируйте свою программу. Разделите программу на составные части таким образом, чтобы все операции root были выполнены заранее, а оставшаяся программа работала в качестве обычного пользователя.

• При изменении или сбрасывании привилегий используйте setresuid(), если она у вас есть. В противном случае используйте setreuid(), поскольку у этих функций самая чистая семантика. Используйте setuid(), лишь когда вы хотите сделать постоянное изменение.

• Переходите от root к обычному пользователю в соответствующем порядке: сначала установите набор групп и значения GID, затем значения UID. Будьте особенно осторожны с fork() и exec(); действительные и эффективные UID при их вызове не изменяются, если вы не измените их явным образом.

• Рассмотрите использование прав доступа setgid и особой группы для вашего приложения. Если это будет работать, это убережет вас от большой головной боли.

• Рассмотрите отказ от наследуемого окружения. Если вам нужно сохранить некоторые переменные окружения, сохраните как можно меньше. Убедитесь в предоставлении подходящих значений для переменных окружения PATH и IFS.

• Избегайте execlp() и execvp(), которые зависят от значения переменной окружения PATH (хотя это менее проблематично, если вы сами восстанавливаете PATH).

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

 

11.9. Рекомендуемая литература

Безопасность Unix (а следовательно, и GNU/Linux) является темой, требующей знаний и опыта для того, чтобы справиться с ней должным образом. В Эпоху Интернета она стала лишь труднее, не проще.

1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O'Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN: 0-596-00323-4.

Это стандартная книга по безопасности Unix.

2. Building Secure Software. How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN: 0-201-72152-X.

Это хорошая книга по написанию безопасного программного обеспечения, она включает проблемы setuid. Предполагается, что вы знакомы с основными API Linux/Unix; к моменту прочтения данной книги вы должны быть готовы к ее прочтению.

3. "Setuid Demystified," by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002 http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf.

Гарфинкель, Спаффорд и Шварц (Garfinkel, Spafford, Schwartz) рекомендуют прочтение этого материала «до того, как вы даже подумаете о написании кода, который пытается сохранять и восстанавливать привилегии». Мы всецело согласны с ними.

 

11.10. Резюме

• Использование значений ID пользователя и группы (UID и GID) для идентификации файлов и процессов — вот что превращает Linux и Unix в многопользовательские системы. Процессы имеют значения как действительных, так и эффективных UID и GID, а также набор дополнительных групп. Обычно именно эффективный UID определяет, как один процесс может повлиять на другой, и эффективные UID, GID и набор групп проверяются на соответствие с правами доступа к файлу. Пользователи с эффективным UID, равным нулю, известные как root или суперпользователи, могут делать все, что захотят; система не использует для такого пользователя проверку прав доступа.

• Концепции сохраненных set-user ID и set-group ID пришли из System V и были приняты POSIX с полной поддержкой в GNU/Linux. Наличие этих отдельных значений ID дает возможность легко и безошибочно переключать при необходимости действительные и эффективные UID (и GID).

• Программы setuid и setgid создают процессы, в которых действительные и эффективные ID различаются. Программы как таковые помечаются дополнительными битами прав доступа к файлу. Биты setuid и setgid должны быть добавлены к файлу после его создания.

• getuid() и geteuid() получают значения действительного и эффективного UID соответственно, a getgid() и getegid() получают значения действительного и эффективного GID соответственно, getgroups() получает набор дополнительных групп, а в среде POSIX может запросить у системы, сколько членов содержит набор групп.

• Функция access() осуществляет проверку прав доступа к файлу для действительного пользователя, давая возможность программе setuid проверить полномочия реального пользователя. Обратите внимание, что часто проверка возвращаемых stat() сведений может не представить полной картины при условии, что файл может находиться на не родной или сетевой файловой системе.

• Функция GLIBC euidaccess() сходна с access(), но осуществляет проверку на основе значений эффективных UID и GID.

• «Липкий» бит и бит setgid при использовании с каталогами привносят дополнительную семантику. Когда для каталога установлен бит setgid, новые файлы в этом каталоге наследуют группу этого каталога. Новые каталоги делают то же самое, они также автоматически наследуют установку бита setgid. Без установленного бита setgid новые файлы и каталоги получают эффективный GID создающего их процесса. «Липкий» бит, установленный для каталогов, в которые в других отношениях разрешена запись, ограничивает право на удаление файла владельцем файла, владельцем каталога и root.

• Набор групп изменяется с помощью setgroups(). Эта функция не стандартизована POSIX, но существует на всех современных системах Unix. Ее может использовать лишь root.

• Изменение UID и GID довольно сложно. Семантика различных системных вызовов с течением времени изменилась. Новые приложения, которые будут изменять лишь свои эффективные UID/GID, должны использовать seteuid() и setegid(). Приложения, не действующие от имени root, могут также устанавливать свои эффективные ID с помощью setuid() и setgid(). Вызовы setreuid() и setregid() от BSD были предназначены для обмена значениями UID и GID; их использование в новых программах не рекомендуется.

• Приложения, действующие как root, могут перманентно заменить значения действительного, эффективного и сохраненного ID с помощью setuid() и setgid(). Одним из таких примеров является login, которая должна превратиться из программы, выполняющейся как root в не непривилегированную зарегистрированную оболочку, выполняющуюся от имени обычного пользователя.

• Функции Linux setresuid() и setresgid() следует использовать всегда, когда они доступны, поскольку они обеспечивают самое чистое и наиболее надежное поведение

• Написание приложений setuid-root не является задачей для новичка. Если вам нужно сделать такую вещь, сначала специально изучите проблемы безопасности. Для этого можно воспользоваться приведенными выше превосходными источниками.

 

Упражнения

1. Напишите простую версию команды id. Ее назначением является отображение в стандартный вывод ID пользователя и группы с указанием имен групп. Когда эффективный и действительный ID различаются, выводятся оба. Например:

$ id

uid=2076(arnold) gid=42(devel) groups=19(floppy), 42(devel), 2076(arnold)

Ее использование:

id [ пользователь ]

id -G [ -nr ] [ пользователь ]

id -g [ -nr ] [ пользователь ]

id -u [ -nr ] [ пользователь ]

При указанном пользователе выводятся сведения об этом пользователе; в противном случае id выводит сведения о пользователе, вызвавшем программу. Опции следующие:

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

 -n  Выводит лишь имена, без числовых значений. Применяется с значениями пользователя и группы.

 -g  Выводит лишь эффективный GID.

 -u  Выводит лишь эффективный UID.

2. Напишите простую программу с именем sume и установите setuid на себя. Она должна запрашивать пароль (см. getpass(3)), который в целях данного примера может быть жестко вшит в исходный код программы. Если лицо, запустившее программу, вводит пароль правильно, sume должна выполнить exec оболочки. Попросите другого пользователя помочь вам ее протестировать.

3. Как вы относитесь к тому, чтобы сделать sume доступной для ваших друзей? Для ваших приятелей студентов или сотрудников? Для каждого пользователя на вашей системе?

 

Глава 12 Общие библиотечные интерфейсы — часть 2

 

В главе 6, «Общие библиотечные интерфейсы — часть 1», был представлен первый набор API библиотеки общего пользования. В некотором смысле, эти API поддерживают работу с фундаментальными объектами, которыми управляют системы Linux и Unix: время дня, пользователи и группы для файлов, сортировка и поиск.

Данная глава более эклектична; функции API, рассмотренные здесь, не особо связаны друг с другом. Однако, все они полезны в повседневном программировании под Linux/Unix. Наше представление движется от простых, более общих функций API к более сложным и более специализированным.

 

12.1. Операторы проверки:

assert()

Оператор проверки (assertion) является утверждением, которое вы делаете о состоянии своей программы в определенный момент времени ее исполнения. Использование операторов проверок для программирования было первоначально разработано Хоаром (C.A.R. Hoare). Общая идея является частью «верификации программы»: так же, как вы проектируете и разрабатываете программу, вы можете показать, что она правильна, делая тщательно аргументированные утверждения о проявлениях кода вашей программы. Часто такие утверждения делаются об инвариантах — фактах о состоянии программы, которые, как предполагается, остаются верными на протяжении исполнения куска программы.

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

/* lsearch --- возвратить индекс с данным значением в массиве или -1,

   если не найдено */

int lsearch(int *array, size_t size, int value) {

 size_t i;

 /* предусловие: array != NULL */

 /* предусловие: size > 0 */

 for (i = 0; i < size; i++)

  if (array[i] == value)

   return i;

 /* постусловие: i == size */

 return -1;

}

Этот пример определяет условия, используя комментарии. Но не было бы лучше проверить условия с использованием кода? Это является задачей макроса assert():

#include /* ISO С */

void assert(/* скалярное выражение */);

Когда скалярное выражение ложно, макрос assert() выводит диагностическое сообщение и завершает программу (с помощью функции abort(); см. раздел 12.4 «Совершение самоубийства: abort()»). ch12-assert.c снова предоставляет функцию lsearch(), на этот раз с оператором проверки и функцией main():

1  /* ch12-assert.с --- демонстрация операторов проверки */

2

3  #include

4  #include

5

6  /* lsearch --- возвращает индекс с данным значением в массиве или -1, если не найдено */

7

8  int lsearch(int *array, size_t size, int value)

9  {

10  size_t i;

11

12  assert(array != NULL);

13  assert(size > 0);

14  for (i = 0; i < size; i++)

15   if (array[i] == value)

16    return i;

17

18  assert(i == size);

19

20  return -1;

21 }

22

23 /* main --- проверить наши условия */

24

25 int main(void)

26 {

27 #define NELEMS 4

28  static int array[NELEMS] = { 1, 17, 42, 91 };

29  int index;

30

31  index = lsearch(array, NELEMS, 21);

32  assert(index == -1);

33

34  index = lsearch(array, NELEMS, 17);

35  assert(index == 1);

36

37  index = lsearch(NULL, NELEMS, 10); /* won't return */

38

39  printf("index = %d\n", index);

40

41  return 0;

42 }

После компиляции и запуска оператор проверки в строке 12 «выстреливает»:

$ ch12-assert /* Запуск программы */

ch12-assert: ch12-assert.c:12: lsearch: Assertion 'array != ((void *)0)' failed.

Aborted (core dumped)

Сообщение от assert() варьирует от системы к системе. Для GLIBC на GNU/Linux сообщение включает имя программы, имя файла с исходным кодом и номер строки, имя функции, а затем текст завершившегося неудачей условия. (В этом случае именованная константа NULL проявляется в виде своего макрорасширения '((void*)0)'.)

Сообщение 'Aborted (core dumped)' означает, что ch12-assert создала файл core; т.е. снимок адресного пространства процесса непосредственно перед его завершением. Этот файл может быть использован впоследствии с отладчиком; см. раздел 15.3 «Основы GDB». Создание файла core является намеренным побочным результатом assert(); предполагается, что произошла решительная ошибка, и вы хотите исследовать процесс с помощью отладчика для ее определения.

Вы можете отменить оператор проверки, компилируя свою программу с помощью опции командной строки '-DNDEBUG'. Когда этот макрос определен до включения , макрос assert() расширяется в код, который ничего не делает. Например:

$ gcc -DNDEBUG=1 ch12-assert.c -о ch12-assert /* Компиляция с -DNDEBUG */

$ ch12-assert /* Запуск */

Segmentation fault (core dumped) /* Что случилось? */

Здесь мы получили настоящий дамп ядра! Мы знаем, что операторы проверки были запрещены; сообщения «failed assertion» нет. Что же случилось? Рассмотрите строку 15 lsearch() при вызове из строки 37 main(). В этом случае переменная array равна NULL. Доступ к памяти через указатель NULL является ошибкой. (Технически различные стандарты оставляют «неопределенным» то, что происходит при разыменовывании указателя NULL. Наиболее современные системы делают то же, что и GNU/Linux; они завершают процесс, посылая ему сигнал SIGSEGV; это, в свою очередь, создает дамп ядра. Этот процесс описан в главе 10 «Сигналы».

Этот случай поднимает важный момент относительно операторов проверки. Часто программисты ошибочно используют операторы проверки вместо проверки ошибок времени исполнения. В нашем случае тест 'array != NULL' должен был быть проверкой времени исполнения:

if (array == NULL) return -1;

Тест 'size > 0' (строка 13) менее проблематичен; если size равен 0 или меньше 0, цикл никогда не исполнится, и lsearch() (правильно) возвратит -1. (По правде, этот оператор проверки не нужен, поскольку код правильно обрабатывает случай 'size <= 0'.)

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

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

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

Наконец, отметим следующее из раздела «Ошибки» справочной страницы GNU/Linux assert(3):

assert() реализован как макрос: если у проверяемого выражения есть побочные результаты, поведение программы может меняться в зависимости от того, определен ли NDEBUG . Это может создавать гейзенберговские ошибки, которые исчезают при отключении режима отладки.

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

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

Справочная страница предостерегает нас от использования при вызовах assert() выражений с побочными эффектами:

assert(*p++ == '\n');

Здесь побочным эффектом является увеличение указателя p как часть теста. Когда определен NDEBUG, аргумент выражения исчезает из исходного кода; он никогда не исполняется. Это может привести к неожиданной неудаче. Однако, как только при подготовке к отладке запрет на операторы проверки отменяется, все начинает снова работать! Такие проблемы трудно отследить.

 

12.2. Низкоуровневая память: функции

mem XXX ()

 

Несколько функций предоставляют возможность для работы с произвольными блоками памяти низкоуровневые службы. Все их имена начинаются с префикса 'mem':

#include /* ISO C */

void *memset(void *buf, int val, size_t count);

void *memcpy(void *dest, const void *src, size_t count);

void *memmove(void *dest, const void *src, size_t count);

void *memccpy(void *dest, const void *src, int val, size_t count);

int memcmp(const void *buf1, const void *buf2, size_t count);

void *memchr(const void *buf, int val, size_t count);

 

12.2.1. Заполнение памяти:

memset()

Функция memset() копирует значение val (интерпретируемое как unsigned char) в первые count байтов буфера buf. Она особенно полезна для обнуления блоков динамической памяти:

void *p = malloc(count);

if (p != NULL)

 memset(p, 0, count);

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

 

12.2.2. Копирование памяти:

memcpy()

,

memmove()

и

memccpy()

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

void *memcpy(void *dest, const void *src, size_t count)

Это простейшая функция. Она копирует count байтов из src в dest. Она не обрабатывает перекрывающиеся области памяти. Функция возвращает dest.

void *memmove(void *dest, const void *src, size_t count)

Подобно memcpy(), она также копирует count байтов из src в dest. Однако, она обрабатывает перекрывающиеся области памяти. Функция возвращает dest.

void *memccpy(void *dest, const void *src, int val, size_t count)

Эта копирует байты из src в dest, останавливаясь либо после копирования val в dest, либо после копирования count байтов. Если она находит val, то возвращает указатель на положение в dest сразу за val. В противном случае возвращается NULL.

Теперь, в чем проблема с перекрывающейся памятью? Рассмотрим рис. 12.1.

Рис. 12.1. Перекрывающиеся копии

Целью является скопировать четыре экземпляра struct xyz от data[0] до data[3] в участок от data[3] до data[6]. Здесь проблемой является data[3], побайтовое копирование с перемещением в памяти из data[0] затрет data[3] до того, как он будет безопасно скопирован в data[6]! (Может возникнуть также сценарий, когда копирование в памяти в обратном направлении разрушит перекрывающиеся данные.)

Функция memcpy() была первоначальной функцией в System V API для копирования блоков памяти; ее поведение для перекрывающихся блоков памяти не была подробно определена тем или иным способом. Для стандарта С 1989 г. комитет почувствовал, что это отсутствие определенности является проблемой, поэтому они придумали memmove(). Для обратной совместимости memcpy() была оставлена, причем поведение для перекрывающейся памяти было специально отмечено как неопределенное, а в качестве процедуры, корректно разрешающей проблемные случаи, была предложена memmove().

Какую из них использовать в своем коде? Для библиотечной функции, которая не знает, какие области памяти ей передаются, следует использовать memmove(). Таким способом вы гарантируете, что не будет проблем с перекрывающимися областями. Для кода приложения, который «знает», что две области не перекрываются, можно безопасно использовать memcpy().

Как для memcpy(), так и для memmove() (как и для strcpy()) буфер назначения является первым аргументом, а источник — вторым. Чтобы запомнить это, обратите внимание на порядок, который тот же самый, как в операторе присваивания:

dest = src;

(Справочные страницы во многих системах не помогают, предлагая прототип в виде 'void *memcpy(void *buf1, void *buf2, size_t n)' и полагаясь на то, что текст объяснит, что есть что. К счастью, справочная страница GNU/Linux использует более осмысленные имена.)

 

12.2.3. Сравнение блоков памяти:

memcmp()

Функция memcmp() сравнивает count байтов из двух произвольных буферов данных. Возвращаемое ею значение подобно strcmp(): отрицательное, нулевое или положительное, если первый буфер меньше, равен или больше второго.

Вы можете поинтересоваться: «Почему бы не использовать для такого сравнения strcmp()?» Разница между двумя функциями в том, что memcmp() не принимает во внимание нулевые байты (завершающий строку '\0'.) Таким образом, memcmp() является функцией, которая используется, когда вам нужно сравнить произвольные двоичные данные.

Другим преимуществом memcmp() является то, что она быстрее типичной реализации на C:

/* memcmp --- пример реализации на С, НЕ для реального использования */

int memcmp(const void *buf1, const void *buf2, size_t count) {

 const unsigned char *cp1 = (const unsigned char*)buf1;

 const unsigned char *cp2 = (const unsigned char*)buf2;

 int diff;

 while (count-- != 0) {

  diff = *cp1++ - *cp2++;

  if (diff != 0)

   return diff;

 }

 return 0;

}

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

По этим причинам всегда следует использовать вашу библиотечную версию memcmp() вместо прокручивания своей собственной. Велика вероятность, что автор библиотеки знает машину лучше вас

 

12.2.4. Поиск байта с данным значением:

memchr()

Функция memchr() сходна с функцией strchr(): она возвращает местоположение определенного значения внутри произвольного буфера. Как и в случае memcmp() против strcmp(), основной причиной для использования memchr() является использование произвольных двоичных данных.

GNU wc использует memchr() при подсчете лишь строк и байтов, и это позволяет wс быть быстрой. Из wc.c в GNU Coreutils:

257  else if (!count_chars && !count_complicated)

258  {

259   /* Использует отдельный цикл при подсчете лишь строк или строк и байтов -

260      но не символов или слов. */

261  while ((bytes_read = safe_read(fd, buf, BUFFER_SIZE)) > 0)

262  {

263   register char *p = buf;

264

265   if (bytes_read == SAFE_READ_ERROR)

266   {

267    error(0, errno, "%s", file);

268    exit_status = 1;

269    break;

270   }

271

272   while ((p = memchr(p, '\n', (buf + bytes_read) - p)))

273   {

274    ++p;

275    ++lines;

276   }

277   bytes += bytes_read;

278  }

279 }

Внешний цикл (строки 261–278) читает блоки данных из входного файла. Внутренний цикл (строки 272–276) использует memchr() для поиска и подсчета символов конца строки. Сложное выражение '(buf + bytes_read) - р' сводится к числу оставшихся байтов между текущим значением p и концом буфера.

Комментарии в строках 259–260 нуждаются в некотором объяснении. Вкратце, современные системы могут использовать символы, занимающие более одного байта в памяти и на диске. (Это несколько более подробно обсуждается в разделе 13.4 «Не могли бы вы произнести это для меня по буквам?».) Таким образом, wc должна использовать другой код, если она различает байты и символы: этот код имеет дело со случаем подсчета байтов.

 

12.3. Временные файлы

 

Временный файл является в точности тем, что звучит в его названии: файл, в котором при исполнении программы хранятся данные, которые больше не нужны после завершения программы. sort читает со стандартного ввода, если в командной строке не указаны файлы или вы используете в качестве имени файла '-'. Тем не менее, sort должна прочесть все свои входные данные, прежде чем сможет вывести отсортированные результаты. (Подумайте об этом немного, и вы увидите, что это так.) Когда читается стандартный ввод, данные должны быть где-то сохранены, прежде чем sort сможет их отсортировать; это отличное применение для временного файла. sort использует временные файлы также для хранения промежуточных результатов сортировки.

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

 

12.3.1. Создание временных имен файлов (плохо)

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

#include

char *tmpnam(char *s); /* ISO С */

char *tempnam(const char *dir, const char *pfx); /* XSI */

char *mktemp(char *template); /* ISO С */

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

char *tmpnam(char *s)

Генерирует уникальное имя файла. Если s не равен NULL, он должен быть размером по крайней мере L_tmpnam байтов, и в него копируется уникальное имя. Если s равен NULL, имя генерируется во внутреннем статическом буфере, который может быть переписан при последующих вызовах. Префикс каталогов в пути будет P_tmpdir. Как P_tmpdir, так и L_tmpnam определены в .

char *tempnam(const char *dir, const char *pfx)

Подобно tmpnam() дает вам возможность указать префикс каталогов. Если dir равен NULL, используется P_tmpdir. Аргумент pfx, если он не равен NULL, определяет до пяти символов для использования в качестве начальных символов имени файла tempnam() выделяет память для имен файлов, которые она генерирует. Возвращенный указатель может впоследствии использоваться с free() (и это следует сделать, если хотите избежать утечек памяти).

char *mktemp(char *template)

Генерирует уникальные имена файлов на основе шаблона. Последними шестью символами template должны быть 'ХХХХХХ'; эти символы замещаются уникальным суффиксом.

ЗАМЕЧАНИЕ . Аргумент template функции mktemp() переписывается. Поэтому он не должен быть строковой константой. Многие компиляторы, предшествовавшие стандарту С, помещают строковые константы в сегмент данных вместе с обычными глобальными переменными. Хотя в исходном коде они определены как константы, их можно переписать, таким образом, нередко встречался такой код:

/* Код в старом стиле: не используйте его */

char *tfile = mktemp("/tmp/myprogXXXXXX");

/* ...использование файла... */

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

Использование этих функций довольно просто. Файл ch12-mktemp.c демонстрирует mktemp(); нетрудно изменить его для использования других функций:

1  /* ch12-mktemp.с --- демонстрирует простое использование mktemp().

2     Для краткости проверка ошибок опущена */

3

4  #include

5  #include /* для флагов открытия */

6  #include /* для PATH_MAX */

7

8  int main(void)

9  {

10  static char template[] = "/tmp/myfileXXXXXX";

11  char fname[PATH_MAX];

12  static char mesg[] =

13   "Here's lookin' at you, kid'\n"; /* вместо "hello, world" */

14  int fd;

15

16  strcpy(fname, template);

17  mktemp(fname);

18

19  /* ОКНО СОСТОЯНИЯ ГОНКИ ОТКРЫВАЕТСЯ */

20

21  printf("Filename is %s\n", fname);

22

23  /* ОКНО СОСТОЯНИЯ ГОНКИ ТЯНЕТСЯ ДОСЮДА */

24

25  fd = open(fname, O_CREAT|O_RDWR|O_TRUNC, 0600);

26  write(fd, mesg, strlen(mesg));

27  close(fd);

28

29  /* unlink(fname); */

30

31  return 0;

32 }

Переменная template (строка 10) определяет шаблон имени файла; 'ХХХХХХ' будет заменен уникальным значением. Строка 16 копирует шаблон в fname, которая не является константой: ее можно изменить. Строка 18 вызывает mktemp() для генерирования имени файла, а строка 21 выводит ее, так, чтобы мы могли видеть, что это такое. (Вскоре мы объясним комментарии в строках 19 и 23.)

Строка 25 открывает файл, создавая его при необходимости. Строка 26 записывает сообщение в mesg, а строка 27 закрывает файл. В программе, в которой файл должен быть удален после завершения работы с ним, строка 29 была бы не закомментирована. (Иногда временный файл не следует удалять; например, если файл после полной записи будет переименован.) Мы закомментировали ее, чтобы можно было запустить эту программу и посмотреть на файл впоследствии. Вот что происходит при запуске программы:

$ ch12-mktemp /* Запуск программы */

Filename is /tmp/myfileQES4WA /* Вывод имени файла */

$ cat /tmp/myfileQES4WA

Here's lookin' at you, kid' /* Содержит то, что ожидалось */

$ ls -l /tmp/myfileQES4WA /* To же с владельцем и доступом */

-rw------- 1 arnold devel 28 Sep 18 09:27 /tmp/myfileQES4WA

$ rm /tmp/myfileQES4WA /* Удалить его */

$ ch12-mktemp / * Используется ли повторно то же имя? */

Filename is /tmp/myfileic7xCy /* Нет. Это хорошо */

$ cat /tmp/myfileic7xCy /* Снова проверить содержание */

Here's lookin' at you, kid!

$ ls -l /tmp/myfileic7xCy /* Снова проверить владельца и доступ */

-rw------- 1 arnold devel 28 Sep 18 09:28 /tmp/myfileic7xCy

Все кажется работающим замечательно, mktemp() возвращает уникальное имя, ch12-mktemp создает файл с нужными правами доступа, и содержание то самое, которое ожидалось. Так в чем же проблема со всеми этими функциями?

Исторически mktemp() использовала простой, предсказуемый алгоритм для создания замещающих символов для 'ХХХХХХ' в шаблоне. Более того, интервал между временем, когда генерируется имя файла, и временем, когда создается сам файл, создает состояние гонки.

Как? Ну, Linux и Unix являются системами с квантованием времени, методикой, которая разделяет время процессора между всеми исполняющимися процессами. Это означает, что, хотя программа кажется выполняющейся все время, в действительности есть моменты, когда процессы спят, т.е. ожидают выполнения на процессоре.

Теперь рассмотрите программу профессора для отслеживания оценок студентов. Как профессор, так и злоумышленный студент в одно и то же время используют сильно нагруженную многопользовательскую систему. Программа профессора использует для создания временных файлов mktemp(), видевший в прошлом, как оценивающая программа создает и удаляет временные файлы, выяснил алгоритм, который использует mktemp(). (В версии GLIBC нет этой проблемы, но не все системы используют GLIBC!) Рис 12.2 иллюстрирует состояние гонки и то, как студент его использует.

Рис. 12.2. Состояние гонки с mktemp()

Вот что случилось.

1. Оценивающая программа использует mktemp() для создания имени файла. По возвращении из mktemp() открыто окно состояния гонки (строка 19 в ch12-.mktemp.c).

2. Ядро останавливает оценивающую программу, чтобы могли поработать другие программы в системе. Это происходит до вызова open().

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

3. Теперь оценивающая программа открывает файл и записывает в него данные. Студент создал файл с правами доступа -rw-rw-rw-, поэтому это не представляет проблему.

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

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

ЗАМЕЧАНИЕ . Мы не рекомендуем делать что-либо из этого! Если вы студент, не пытайтесь сделать что-либо подобное. Первое и самое главное, это неэтично. Во-вторых, вас могут выгнать из школы. В-третьих, ваши профессора, наверное, не сталь наивны, чтобы использовать mktemp() в своих программах. Этот пример лишь для иллюстрации!

По приведенным и другим причинам, все три описанные в данном разделе функции не следует никогда использовать. Они существуют в POSIX и GLIBC лишь для поддержки старых программ, которые были написаны до того, как была осознана опасность этих процедур С этой целью системы GNU/Linux генерируют во время компоновки сообщение:

$ cc ch12-mktemp.c -о ch12-mktemp /* Компилировать программу */

/tmp/cc1XCvD9.о(.text+0x35): In function 'main':

: the use of 'mktemp' is dangerous, better use 'mkstemp'

(Мы рассмотрим mkstemp() в следующем подразделе.)

Если бы в вашей системе не было mkstemp(), подумайте, как вы могли бы использовать эти интерфейсы для ее эмулирования. (См. также «Упражнения» для главы 12 в конце.)

 

12.3.2. Создание и открывание временных файлов (хорошо)

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

#include /* ISO С */

FILE *tmpfile(void);

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

#include /* XSI */

int mkstemp(char* template);

tmpfile() возвращает значение FILE*, представляющее уникальный открытый временный файл. Файл открывается в режиме "w+b". w+ означает «открыть для чтения и записи, сначала урезав файл», a b означает двоичный, а не текстовый режим. (На системах GNU/Linux или Unix нет разницы, но на других системах есть.) Файл автоматически удаляется, когда закрывается указатель файла; нет способа получить имя файла, чтобы сохранить его содержимое. Программа в ch12-tmpfile.c демонстрирует tmpfile():

/* ch12-tmpfile.с --- демонстрация tmpfile().

   Проверка ошибок для краткости опущена */

#include

int main(void) {

 static char mesg[] =

  "Here's lookin' at you, kid!"; /* заменяет "hello, world" */

 FILE *fp;

 char buf[BUFSIZ];

 fp = tmpfile();                 /* Получить временный файл */

 fprintf(fp, "%s", mesg);        /* Записать s него */

 fflush(fp);                     /* Сбросить на диск */

 rewind(fp);                     /* Перейти в начало */

 fgets(buf, sizeof buf, fp);     /* Прочесть содержимое */

 printf("Got back <%s>\n", buf); /* Вывести полученные данные */

 fclose(fp);                     /* Закрыть файл, закончить */

 return 0;                       /* Все сделано */

}

Возвращенное значение FILE* не отличается от любого другого FILE*, возвращенного fopen(). При запуске получаем ожидавшиеся результаты:

$ ch12-tmpfile

Got back

Ранее мы видели, что авторы GLIBC рекомендуют использование функции mkstemp():

$ cc ch12-mktemp.с -о ch12-mktemp /* Компилировать программу */

/tmp/cc1XCvD9.о(.text+0x35): In function "main':

: the use of 'mktemp' is dangerous, better use 'mkstemp'

Эта функция похожа на mktemp() в том, что она принимает имя файла, оканчивающееся на 'ХХХХХХ', и заменяет эти символы уникальным суффиксом для создания уникального имени файла. Однако, она идет на один шаг дальше. Она создает и открывает файл. Файл создается с доступом 0600 (т.е. -rw-------). Таким образом, доступ к файлу может получить только пользователь, запустивший программу.

Более того, и это то, что делает mkstemp() более безопасной, файл создается с флагом O_EXCL, который гарантирует, что файл не существует, и не дает никому больше открыть файл.

Возвращаемое значение является дескриптором открытого файла, который может использоваться для чтения и записи. Для удаления файла после завершения работы с ним должно использоваться имя пути, сохраненное теперь в переданном mkstemp() буферу. Все это демонстрируется в ch12-mkstemp.c, который является простой модификацией ch12-tmpfile.с:

/* ch12-mkstemp.с --- демонстрирует mkstemp().

   Проверка ошибок для краткости опущена */

#include

#include /* для флагов открытия */

#include /* для PATH_МАХ */

int main(void) {

 static char template[] = "/tmp/myfileXXXXXX";

 char fname[PATH_MAX];

 static char mesg[] =

  "Here's lookin' at you, kid!\n"; /* заменяет "hello, world" */

 int fd;

 char buf[BUFSIZ];

 int n;

 strcpy(fname, template);           /* Копировать шаблон */

 fd = mkstemp(fname);               /* Создать и открыть временный файл */

 printf("Filename is %s\n", fname); /* Вывести его для сведений */

 write(fd, mesg, strlen(mesg));     /* Что-нибудь записать в файл */

 lseek(fd, 0L, SEEK_SET);           /* Перейти в начало */

 n = read(fd, buf, sizeof(buf));

  /* Снова прочесть данные; НЕ завышается '\0'! */

 printf("Got back: %.*s", n, buf);  /* Вывести его для проверки */

 close(fd);                         /* Закрыть файл */

 unlink(fname);