Linux API. Исчерпывающее руководство полностью

Структура rusage, возвращаемая операцией RUSAGE_CHILDREN для вызова getrusage(), включает в себя статистику о потреблении ресурсов для всех потомков вызывающего процесса. Представьте, к примеру, что у нас есть три процесса с иерархией «родитель —> сын —> внук»; когда сын делает вызов wait() для внука, сведения о потреблении ресурсов внуком добавляются к значениям RUSAGE_CHILDREN сына; когда вызов wait() выполняет родитель, к его значениям RUSAGE_CHILDREN добавляются сведения о потреблении ресурсов как сыном, так и внуком. И наоборот, если сын не выполняет wait() для внука, статистика использования ресурсов, принадлежащая внуку, не учитывается в значениях RUSAGE_CHILDREN родителя.

Для операции RUSAGE_CHILDREN поле ru_maxrss максимальный размер страницы памяти во всех потомках вызывающего процесса (вместо суммарного объема).

В стандарте SUSv3 говорится о том, что если сигнал SIGCHLD игнорируется (чтобы дочерние процессы не превратились в «зомби», для которых можно сделать вызов wait()), статистика о потомке не должна добавляться в значения, возвращаемые операцией RUSAGE_CHILDREN. Но, как отмечалось в подразделе 26.3.3, до версии 2.6.9 ядра Linux не следовали этому требованию — если сигнал SIGCHLD игнорируется, сведения о потреблении ресурсов завершенными потомками попадают в итоговый результат операции RUSAGE_CHILDREN.

Каждый процесс обладает набором ограничений, с помощью которых можно ограничить объем тех или иных системных ресурсов, которые тот может потребить. Например, если мы боимся, что программа может потребовать слишком много ресурсов, перед ее запуском для нее можно установить определенные ограничения. Это можно сделать с помощью команды ulimit, встроенной в оболочку (или limit, если это csh). Эти ограничения наследуются процессами, которые создаются командной оболочкой для выполнения пользовательских программ.

Начиная с ядра 2.6.24 к файлу /proc/PID/limits, доступный только в Linux, можно обращаться для просмотра всех ограничений на ресурсы для любого процесса. Этому файлу назначен реальный идентификатор пользователя соответствующего процесса, и читать его может только этот пользователь (или привилегированный процесс).

Сведения о ограничениях на ресурсы процесса можно получать и изменять с помощью системных вызовов getrlimit() и setrlimit().

#include

int getrlimit(int resource, struct rlimit *rlim);

int setrlimit(int resource, const struct rlimit *rlim);

Возвращает 0 при успешном завершении или –1, если случилась ошибка

Аргумент resource обозначает ограничение на ресурсы, которое нужно получить или изменить. Аргумент rlim используется либо для возвращения существующих значений ограничения (в getrlimit()), либо для задания новых (в setrlimit()); он представляет собой структуру, состоящую из двух полей:

struct rlimit {

rlim_t rlim_cur; /* Мягкое ограничение (настоящее ограничение для процесса) */

rlim_t rlim_max; /* Жесткое ограничение (максимальное значение rlim_cur) */

};

Эти поля имеют целочисленный тип rlim_t и соответствуют двум ограничениям на один ресурс: мягкому (rlim_cur) и жесткому (rlim_max). Мягкое ограничение регулирует количество ресурсов, которые могут быть использованы процессом. Процесс может присваивать ему любое значение от 0 до жесткого ограничения. В большинстве ресурсов жесткое ограничение служит исключительно для предоставления этого максимума. Привилегированный процесс (CAP_SYS_RESOURCE) может изменять его в любую сторону (до тех пор пока он превышает мягкое ограничение), однако обычные процессы могут его только уменьшать (без возможности отменить изменения). Значение RLIM_INFINITY, если его присвоить или извлечь из поля rlim_cur или rlim_max с помощью вызовов getrlimit() или setrlimit(), делает ограничение бесконечным.

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

Значения, которые можно указать в аргументе resource для вызовов getrlimit() и setrlimit(), перечислены в табл. 36.1 и подробно рассматриваются в разделе 36.3.