Операционная система UNIX - Андрей Робачевский

 if (rlm.rlim_max == RLIM_INFINITY)

  printf("infinite n");

 else

  printf("%10ldn", rlm.rlim_max);

}

main() {

 disp_limit(RLIMIT_CORE, "RLIMIT_CORE");

 disp_limit(RLIMIT_CPU, "RLIMIT_CPU");

 disp_limit(RLIMIT_DATA, "RLIMIT_DATA");

 disp_limit(RLIMIT_FSIZE, "RLIMIT_FSIZE");

 disp_limit(RLIMIT_NOFILE, "RLIMIT_NOFILE");

 disp_limit(RLIMIT_STACK, "RLIMIT_STACK");

 /* BSD */

#ifdef RLIMIT_NPROC

 disp_limit(RLIMIT_NPROC, "RLIMIT_NPROC");

#endif

 /* BSD */

#ifdef RLIMIT_RSS

 disp_limit(RLIMIT_RSS, "RLIMIT_RSS");

#endif

 /* BSD */

#ifdef RLIMIT_MEMLOCK

 disp_limit(RLIMIT_MEMLOCK, "RLIMIT_MEMLOCK");

#endif

 /* System V */

#ifdef RLIMIT_VMEM

 disp_limit(RLIMIT_VMEM, "RLIMIT_VMEM");

#endif

}

Запуск программы под управлением операционной системы Solaris 2.5 даст следующие результаты:

$ а.out

RLIMIT_CORE   infinite   infinite

RLIMIT_CPU    infinite   infinite

RLIMIT_DATA   2147479552 2147479552

RLIMIT_FSIZE  infinite   infinite

RLIMIT_NOFILE 64         1024

RLIMIT_STACK  8388608    2147479552

RLIMIT_VMEM   infinite   infinite

Примеры программ

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

Демон

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

Некоторые демоны работают постоянно, наиболее яркий пример такого демона — процесс init(1M), являющийся прародителем всех прикладных процессов в системе. Другими примерами являются cron(1M), позволяющий запускать программы в определенные моменты времени, inetd(1M) обеспечивающий доступ к сервисам системы из сети, и sendmail(1M), обеспечивающий получение и отправку электронной почты.

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

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

2. Необходимо закрыть все открытые файлы (файловые дескрипторы), особенно стандартные потоки ввода/вывода. Многие из этих файлов представляют собой терминальные устройства, которые должны быть закрыты, например, при выходе пользователя из системы. Предполагается, что демон остается работать и после того, как пользователь "покинул" UNIX.

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

4. Сообщения о работе демона следует направлять в специальный журнал с помощью функции syslog(3), — это наиболее корректный способ передачи сообщений от демона.

5. Необходимо изменить текущий каталог на корневой. Если этого не сделать, а текущий каталог, допустим, находится на примонтированной файловой системе, последнюю нельзя будет размонтировать. Самым надежным выбором является корневой каталог, всегда принадлежащий корневой файловой системе.

Приведем скелет программы-демона:

#include <stdio.h>

#include <syslog.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/param.h>

#include <sys/resource.h>

main(int argc, char **argv) {

 int fd;

 struct rlimit flim;

 /* Если родительский процесс — init, можно не беспокоиться

    за терминальные сигналы. Если нет — необходимо игнорировать

    сигналы, связанные с вводом/выводом на терминал

    фонового процесса: SIGTTOU, SIGTTIN, SIGTSTP */

 if (getppid() != 1) {

  signal(SIGTTOU, SIG_IGN);

  signal(SIGTTIN, SIG_IGN);

  signal(SIGTSTP, SIG_IGN);

  /* Теперь необходимо организовать собственную группу и сеанс,

     не имеющие управляющего терминала. Однако лидером группы и

     сеанса может стать процесс, если он еще не является лидером.

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

     необходима гарантия, что наш процесс не является лидером.

     Для этого порождаем дочерний процесс. Т.к. его PID уникален,

     то ни группы, ни сеанса с таким идентификатором не существует,

     а значит нет и лидера. При этом родительский процесс

     немедленно завершает выполнение, поскольку он уже не нужен.

     Существует еще одна причина необходимости порождения

     дочернего процесса. Если демон был запущен из командной строки

     командного интерпретатора shell не в фоновом режиме,

     последний будет ожидать завершения выполнения демона,

     и таким образом, терминал будет заблокирован.

     Порождая процесс и завершая выполнение родителя,

     имитируем для командного интерпретатора завершение

     работы демона, после чего shell выведет свое приглашение */

  if (fork () !=0)

   exit(0); /* Родитель заканчивает работу */

   /* Дочерний процесс с помощью системного вызова

      становится лидером новой группы, сеанса и не имеет

      ассоциированного терминала */[28]

 }

 /* Теперь необходимо закрыть открытые файлы. Закроем

    все возможные файловые дескрипторы. Максимальное число

    открытых файлов получим с помощью функции getrlimit */

 getrlimit(RLIMIT_NOFILE, &flim);

 for (fd = 0; fd < flim.rlim_max; fd++)

  close(fd);

 /* Сменим текущий каталог на корневой */

  chdir("/");

 /* Заявим о себе в системном журнале. Для этого сначала

    установим опции ведения журнала: каждая запись будет

    предваряться идентификатором PID демона, при невозможности

    записи в журнал сообщения будут выводиться на консоль,

    источник сообщений определим как "системный демон"

    (см. комментарии к функциям ведения журнала ниже). */

 openlog("Скелет демона" , LOG_PID | LOG_CONS, LOG_DAEMON);

 /* Отметимся */

 syslog(LOG_INFO, "Демон начал плодотворную работу...");

 closelog();

 /* Далее следует текст программы, реализующий полезные функции

    демона. Эта часть предоставляется читателю для собственной

    разработки. */

 ...

}

В программе использовалось еще не обсуждавшаяся возможность системного журнала сообщений выполняющихся программ. Функцией генерации сообщений является syslog(3), отправляющая сообщение демону системного журнала syslogd(1M), который в свою очередь либо дописывает сообщения в системный журнал, либо выводит на их консоль, либо перенаправляет в соответствии со списком пользователей данной или удаленной системы. Конкретный пункт назначения определяется конфигурационным файлом (/etc/syslog.conf). Функция имеет определение:

#include <syslog.h>

void syslog(int priority, char *logstring, /* параметры*/...);

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