getrandom

title: getrandom(2)

summary: возвращает серию произвольных байт

text:
# getrandom(2)

## ИМЯ
getrandom - возвращает серию произвольных байт

## ОБЗОР
\#include <sys/random.h>

ssize_t getrandom(void *buf, size_t buflen, unsigned int flags);

## ОПИСАНИЕ
Системный вызов getrandom() заполняет буфер, указанный в buf, произвольными байтами в количестве до buflen. Эти байты можно использовать как начальные значения в генераторах произвольных чисел пространства пользователя или с целями шифрования.

По умолчанию, getrandom() забирает энтропию из источника urandom (т. е., того же источника что и устройство /dev/urandom). Это поведение можно изменить через параметр flags.

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

Если источник urandom ещё не инициализирован, то вызов getrandom() блокируется, если в flags не указано значение GRND_NONBLOCK.

Аргумент flags является битовой маской, которая может содержать ноль или более следующих флагов:

GRND_RANDOM

Если этот бит установлен, то произвольные байты берутся из источника random (т. е., того же источника что и устройство /dev/urandom), а не из источника urandom. Ограничение источника random следует из энтропии, которую можно получить из окружающего шума. Если количество доступных байт в random меньше запрашиваемых в buflen, то вызов завершается сразу после выдачи всех доступных произвольных байт. Если произвольных байт нет, то поведение зависит от наличия флага GRND_NONBLOCK в параметре flags.

GRND_NONBLOCK

По умолчанию, при чтении из источника random вызов getrandom() блокируется, если произвольные байты недоступны, и а при чтении из источника urandom блокируется, если ещё не инициализирован пул энтропии. Если указан флаг GRND_NONBLOCK, то в этих случаях getrandom() не блокируется, а сразу возвращает -1 и присваивает errno значение EAGAIN.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении getrandom() возвращает количество скопированных в буфер buf байт. Это значение может быть меньше, чем количество запрашиваемых в buflen байт, если в flags был указан GRND_RANDOM и нет достаточного количества энтропии в источнике random, или если системный вызов был прерван сигналом.

В случае ошибки возвращается -1 и значение errno устанавливается соответствующим образом.

## ОШИБКИ
EAGAIN

Запрошенное количество энтропии недоступно, и getrandom() заблокировался бы, если бы отсутствовал флаг GRND_NONBLOCK.

EFAULT

Адрес, указанный в buf, лежит вне доступного адресного пространства.

EINTR

Вызов был прерван обработчиком сигнала; смотрите описание о прерывании вызовов read(2) при работе с «медленными» устройствами и при отсутствии флага SA_RESTART в справочной странице signal(7).

EINVAL

В flags указан неверный флаг.

ENOSYS

Обёрточная функция в glibc для getrandom() определила, что используемое ядро не поддерживает данный системный вызов.

## ВЕРСИИ
Вызов getrandom() появился в версии ядра Linux 3.17. Поддержка в glibc добавлена в версии 2.5.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Данный вызов есть только в Linux.

## ЗАМЕЧАНИЯ
Обзор и сравнение возможных интерфейсов, через которые можно получать случайные данные, смотрите в random(7).

В отличие от /dev/random и /dev/urandom, в вызове getrandom() не используются пути или файловые дескрипторы. Таким образом, getrandom() полезен в случаях, когда chroot(2) делает пути /dev невидимыми и приложение (например, служба во время загрузки) закрывает файловый дескриптор одного из этих файлов, которые были открыты библиотекой.

### Возвращается максимальное количество байтов
На момент Linux 3.19 существуют следующие ограничения:

- При чтении из источника urandom в системах, где размер int равен 32 битам, один вызов getrandom() возвращает максимум 33554431 байт.

- При чтении из источника random возвращается максимум 512 байт.

### Прерывание обработчиком сигнала
При чтении из источника urandom (GRND_RANDOM не указан), getrandom() блокируется до тех пор, пока не специализируется пул энтропии (если не указан флаг GRND_NONBLOCK). Если запрос требует большого количества байт (больше 256), getrandom() будет заблокирован до тех пор, пока байты не будут сгенерированы и переданы из памяти ядра в buf. При чтении из random (указан GRND_RANDOM), getrandom() будет заблокирован до тех пор, пока какое-то количество произвольных байт не станет доступно (если не указан флаг GRND_NONBLOCK).

Поведение при прерывании обработчиком сигнала вызова getrandom(), заблокированного чтением источника urandom, зависит от состояния инициализации буфера энтропии и от запрашиваемого объёма buflen. Если энтропия ещё не инициализирована, то вызов завершается ошибкой EINTR. Если пул энтропии инициализирован и запрашиваемый объём большой (buflen > 256), то вызов или завершится успешно, вернув частично заполненный буфер, или завершится с ошибкой EINTR. Если пул энтропии инициализирован и запрашиваемый объём мал (buflen <= 256), то getrandom() завершится без ошибки EINTR. Вместо этого, он вернёт все запрашиваемый байты.

При чтении из источника random блокирующие запросы на любой объём могут быть прерваны обработчиком сигналом (вызов завершается с ошибкой EINTR).

Использование getrandom() для чтения маленьких буферов (<= 256 байт) из источника urandom — предпочтительный способ использования.

Специальный режим для маленького объёма buflen был разработан для совместимости с системным вызовом getentropy(3) из OpenBSD, который теперь поддерживается glibc.

Пользователь getrandom() всегда должен проверять возвращаемое значение, чтобы определить что возникла ошибка или возвращено меньшее количество запрошенных байт. В случае когда флаг GRND_RANDOM не указан и значение buflen меньше или равно 256, возврат меньшего количества байт чем запрошено никогда не происходит, но осторожный программист всегда проверяет значение!

## ДЕФЕКТЫ
В Linux 3.19 существуют следующие дефекты:

*

В зависимости от загруженности ЦП, getrandom() не реагирует на прерывания, пока не прочитает все запрашиваемые байты.

## СМОТРИТЕ ТАКЖЕ
getentropy(3), random(4), urandom(4), random(7), signal(7)


getresuid

package: man-pages-ru

title: getresuid(2)

text:
# getresuid(2)

## ИМЯ
getresuid, getresgid - получение действительного, эффективного и сохранённого идентификатора пользователя или группы

## ОБЗОР
\#define _GNU_SOURCE /* смотрите feature_test_macros(7) */

\#include <unistd.h>

int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);

int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid);

## ОПИСАНИЕ
getresuid() возвращает действительный (real), эффективный (effective) и сохранённый (saved) set-user-ID идентификатор пользователя вызывающего процесса в аргументах ruid, euid и suid, соответственно. getresgid() выполняет аналогичную задачу для идентификаторов группы процесса.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении возвращается 0. В случае ошибки возвращается -1, а errno устанавливается в соответствующее значение.

## ОШИБКИ
EFAULT

В одном из аргументов задан адрес вне области адресного пространства вызывающей программы.

## ВЕРСИИ
Данные системные вызовы появились в Linux, начиная с ядра версии 2.1.44.

В glibc прототипы появились в версии 2.3.2, они предоставляются при определении _GNU_SOURCE.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Это нестандартные вызовы; также они есть в HP-UX и некоторых BSD.

## ЗАМЕЧАНИЯ
Первоначальные версии системных вызовов getresuid() и getresgid() в Linux поддерживали только 16-битные идентификаторы пользователей и групп. Позднее в Linux 2.4 были добавлены вызовы getresuid32() и getresgid32(), поддерживающие 32-битные идентификаторы. В glibc обёрточные функции getresuid() и getresgid() работают одинаково вне зависимости от версий ядра.

## СМОТРИТЕ ТАКЖЕ
getuid(2), setresuid(2), setreuid(2), setuid(2), credentials(7)

branch: sisyphus


getrlimit

title: getrlimit(2)

summary: считывает/устанавливает ограничения

text:
# getrlimit(2)

## ИМЯ
getrlimit, setrlimit, prlimit - считывает/устанавливает ограничения использования ресурсов

## ОБЗОР
\#include <sys/time.h>

\#include <sys/resource.h>

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

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

int prlimit(pid_t pid, int resource, const struct rlimit *new_limit,

struct rlimit *old_limit);

Требования макроса тестирования свойств для glibc (см. feature_test_macros(7)):

prlimit(): _GNU_SOURCE

## ОПИСАНИЕ
Системные вызовы getrlimit() и setrlimit() получают и устанавливают ограничения использования ресурсов. Каждому ресурсу назначается мягкое и жёсткое ограничение, определяемое структурой rlimit:

```
struct rlimit {

    rlim_t rlim_cur;  /* мягкое ограничение */

    rlim_t rlim_max;  /* жёсткое ограничение (максимум для rlim_cur) */
};
```

Мягким ограничением является значение, принудительно устанавливаемое ядром для соответствующего ресурса. Жёсткое ограничение работает как максимальное значение для мягкого ограничения: непривилегированные процессы могут определять только свои мягкие ограничения в диапазоне от 0 до жёсткого ограничения, то есть однозначно меньше жёсткого ограничения. Привилегированные процессы (в Linux: имеющие мандат CAP_SYS_RESOURCE в начальном пространстве имён пользователя) могут устанавливать произвольные значения в любых пределах.

Значение RLIM_INFINITY означает отсутствие ограничений для ресурса (в структуре, возвращаемой getrlimit() и в структуре, передаваемой в setrlimit()).

Значение resource должно быть одним из:

RLIMIT_AS

Максимальный размер виртуальной памяти (адресного пространства) процесса. Данное ограничение задаётся в байтах и округляется в меньшую сторону к размеру системной страницы. Учитывается в вызовах brk(2), mmap(2) и mremap(2), которые завершатся с ошибкой ENOMEM, если будет превышено это ограничение. К тому же завершается ошибкой автоматическое расширение стека (и генерируется сигнал SIGSEGV, по которому процесс завершится, если не было создано с помощью sigaltstack(2) альтернативного стека). Так как значение имеет тип long, на машинах с 32-битным long максимальное значение ограничения будет около 2 ГиБ, или этот ресурс не ограничивается.

RLIMIT_CORE

Максимальный размер файла core (смотрите core(5)) в байтах, который может получиться из процесса. Если значение равно 0, то файлы core не создаются. Если значение больше нуля, то создаваемые дампы обрезаются до этого размера.

RLIMIT_CPU

Ограничение времени выполнения процесса на ЦП в секундах. Когда процесс достигает своего мягкого ограничения, то ему отправляется сигнал SIGX CPU. Действием по умолчанию для этого сигнала является завершение процесса. Однако, этот сигнал может быть перехвачен, и обработчик может передать управление в основную программу. Если процесс продолжает потреблять процессорное время, то ему будет отправляться SIGXCPU раз в секунду до тех пор, пока не будет достигнуто жёсткое ограничение, и тогда процессу будет послан сигнал SIGKILL (последний пункт описывает поведение Linux. В разных реализациях действия над потребляющими процессорное время после прохождения мягкого ограничения процессами различаются. Переносимые приложения, где требуется перехват сигнала, должны выполнять корректное завершение процесса после первого получения SIGXCPU).

RLIMIT_DATA

Максимальный размер сегмента данных процесса (инициализированные данные, неинициализированные данные, куча). Данное ограничение задаётся в байтах и округляется в меньшую сторону к размеру системной страницы. Это ограничение учитывается в вызовах brk(2), sbrk(2) и (начиная с Linux 4.7) mmap(2), которые завершатся с ошибкой ENOMEM при достижении мягкого ограничения этого ресурса.

RLIMIT_FSIZE

Максимальный размер (в байтах) файлов, создаваемых процессом. Попытки расширить файл сверх этого ограничения приведёт к доставке сигнала SIGXFSZ. По умолчанию по этому сигналу процесс завершается, но процесс может перехватить этот сигнал и в этом случае выполнявшийся системный вызов (например, write(2), truncate(2)) завершится с ошибкой EFBIG.

RLIMIT_LOCKS (только в ранних версиях Linux 2.4)

Ограничение на общее количество блокировок flock(2) и аренд fcntl(2), которое может установить процесс.

RLIMIT_MEMLOCK

Максимальное количество байт памяти, которое может быть заблокировано в ОЗУ. В целях эффективности это ограничение округляется в меньшую сторону до ближайшего значения, кратного размеру системной страницы. Это ограничение учитывается в mlock(2), mlockall(2) и в mmap(2) при операции MAP_LOCKED. Начиная с Linux 2.6.9, оно также учитывается в shmctl(2) при операции SHM_LOCK, где определяет максимальное количество байт всех общих сегментов памяти (смотрите shmget(2)), которые могут быть заблокированы вызывающим процессом с реальным идентификатором пользователя. Блокировки по операции SHM_LOCK у shmctl(2) учитываются отдельно от попроцессных блокировок памяти, устанавливаемых mlock(2), mlockall(2) и mmap(2) с операцией MAP_LOCKED; процесс может заблокировать пространство до этого значения заданного ограничения байт в каждой из этих двух категорий.

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

RLIMIT_MSGQUEUE (начиная с Linux 2.6.8)

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

Начиная Linux 3.5:

```
        bytes = attr.mq_maxmsg * sizeof(struct msg_msg) +

                min(attr.mq_maxmsg, MQ_PRIO_MAX) *

                      sizeof(struct posix_msg_tree_node)+

                                /* издержки */

                attr.mq_maxmsg * attr.mq_msgsize;

                                /* данные из сообщения */

```

Linux 3.4 и старше:

```
        bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) +

                                /* издержки */

                attr.mq_maxmsg * attr.mq_msgsize;

                                /* данные из сообщения */

```

где attr — структура mq_attr, указанная в четвёртом аргументе mq_open(3), а msg_msg и posix_msg_tree_node — внутренние структуры ядра.

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

RLIMIT_NICE (начиная с Linux 2.6.12, см. ДЕФЕКТЫ далее)

Определяет максимум, до которого может быть увеличено значение уступчивости процесса с помощью setpriority(2) или nice(2). Действительный максимум значения уступчивости высчитывается по формуле: 20 - rlim_cur. Полезным диапазоном этого ограничения являются значения от 1 (соответствует значению уступчивости 19) до 40 (соответствует значению уступчивости -20). Так пришлось поступить из-за того, что отрицательные числа нельзя указывать в значениях ограничений ресурсов, так как они, обычно, имеют специальное предназначение. Например, RLIM_INFINITY, обычно равно -1. Более подробно о значениях уступчивости описано в sched(7).

RLIMIT_NOFILE

Определяет значение, на 1 больше максимального количества дескрипторов файлов, которое может открыть этот процесс. Попытки (open(2), pipe(2), dup(2) и т.п.) превысить это ограничение приведут к ошибке EMFILE (раньше это ограничение в BSD называлось RLIMIT_OFILE).

Начиная с Linux 4.5, это ограничение также определяет максимальное количество файловых дескрипторов, которое непривилегированный процесс (не имеющий мандата CAP_SYS_RESOURCE) может держать «пересылать» (in flight) другим процессам через доменные сокеты UNIX. Данное ограничение применяется только к системному вызову sendmsg(2). Дополнительную информацию смотрите в unix(7).

RLIMIT_NPROC

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

Данное ограничение не учитываются процессы, имеющие мандат CAP_SYS_ADMIN или CAP_SYS_RESOURCE.

RLIMIT_RSS

Максимальное ограничение (в байтах) размера постоянного присутствия процесса (числа виртуальных страниц, постоянно присутствующих в ОЗУ). Это ограничение учитывается только начиная с версии Linux 2.4.x, x < 30, и только в вызовах madvise(2) со значением MADV_WILLNEED.

RLIMIT_RTPRIO (начиная с Linux 2.6.12, смотрите ДЕФЕКТЫ)

Определяет максимум для приоритета реального времени, который можно установить для процесса с помощью sched_setscheduler(2) и sched_setparam(2).

Дополнительную информацию об алгоритмах планирования реального времени смотрите в sched(7).

RLIMIT_RTTIME (начиная с Linux 2.6.25)

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

При достижении мягкого ограничения процессу посылается сигнал SIGXCPU. Если процесс перехватил сигнал, проигнорировал его и продолжает потреблять время ЦП, то раз в секунду будет генерироваться сигнал SIGXCPU до тех пор, пока не будет достигнуто жёсткое ограничение, и процессу не будет послан сигнал SIGKILL.

Это ограничение предназначено для предотвращения блокировки системы вышедшими из под контроля процессами реального времени.

Дополнительную информацию об алгоритмах планирования реального времени смотрите в sched(7).

RLIMIT_SIGPENDING (начиная с Linux 2.6.8)

Определяет ограничение на количество сигналов, которые могут быть поставлены в очередь вызывающего процесса с реальным пользовательским идентификатором. При проверке ограничения учитываются обычные сигналы и сигналы реального времени. Однако ограничение учитывается только в sigqueue(3); всегда возможно использовать kill(2) для постановки в очередь любого сигнала, которого ещё нет в очереди процесса.

RLIMIT_STACK

Максимальный размер стека процесса в байтах. При достижении этого ограничения генерируется сигнал SIGSEGV. Для обработки этого сигнала процесс должен использовать альтернативный стек сигналов (sigaltstack(2)).

Начиная с Linux 2.6.23, это ограничение также определяет количество места, используемого для аргументов командной строки процесса и его переменных окружения; подробней об этом смотрите в execve(2).

### prlimit()
Системный вызов prlimit(), который есть только в Linux объединяет и расширяет функции setrlimit() и getrlimit(). Он может использоваться для задания и получения ограничений ресурсов произвольного процесса.

Аргумент resource имеет тот же смысл что и в setrlimit() и getrlimit().

Если значение аргумента new_limit не равно NULL, то структура rlimit, на которую он указывает, используется для задания новых значений мягкий и жёстких ограничений для resource. Если значение аргумента old_limit не равно NULL, то успешный вызов prlimit() помещает текущие значения мягких и жёстких ограничений для resource в структуру rlimit, на которую указывает old_limit.

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

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении возвращается 0. В случае ошибки возвращается -1, а errno устанавливается в соответствующее значение.

## ОШИБКИ
EFAULT

Аргумент-указатель указывает за пределы доступного адресного пространства.

EINVAL

Указано некорректное значение resource; или для setrlimit() или prlimit(): rlim->rlim_cur больше чем rlim->rlim_max.

EPERM

Непривилегированный процесс пытался увеличить жёсткое ограничение; для этого требуется мандат CAP_SYS_RESOURCE.

EPERM

Вызывающий пытался увеличить жёсткое ограничение RLIMIT_NOFILE, превышая максимум, заданный в /proc/sys/fs/nr_open (смотрите proc(5)).

EPERM

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

ESRCH

Не удалось найти процесс с идентификатором, указанном в pid.

## ВЕРСИИ
Системный вызов prlimit() появился в Linux 2.6.36. Поддержка в glibc доступна начиная с версии 2.13.

## АТРИБУТЫ
Описание терминов данного раздела смотрите в attributes(7).

Интерфейс

Атрибут

Значение

getrlimit(), setrlimit(), prlimit()

Безвредность в нитях

MT-Safe

## СООТВЕТСТВИЕ СТАНДАРТАМ
getrlimit(), setrlimit(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.

prlimit(): только в Linux.

Ограничение RLIMIT_MEMLOCK и RLIMIT_NPROC появились из BSD и их нет в POSIX.1; они есть в BSD и Linux, но реализации несколько различны. Ограничение RLIMIT_RSS появилось из BSD и его нет в POSIX.1; тем не менее оно есть в большинстве реализаций. Ограничения RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO, RLIMIT_RTTIME и RLIMIT_SIGPENDING есть только в Linux.

## ЗАМЕЧАНИЯ
Дочерний процесс, созданный fork(2), наследует ограничения ресурсов родителя. Ограничения ресурсов сохраняются при execve(2).

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

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

Ограничения ресурсов интерпретатора командной строки можно устанавливать с помощью встроенной команды ulimit (limit в csh(1)). Ограничения ресурсов интерпретатора наследуются дочерними процессами, которые он создаёт при выполнении команд.

Начиная с Linux 2.6.24, ограничения ресурсов любого процесса можно узнать с помощью /proc/[pid]/limits; смотрите proc(5).

В старых системах была функция vlimit() с подобным setrlimit() назначением. Для обратной совместимости в glibc также есть функция vlimit(). Во всех новых приложениях должен быть использован setrlimit().

### Отличия между библиотекой C и ABI ядра
Начиная с версии 2.13, обёрточные функции glibc getrlimit() и setrlimit() больше не вызывают соответствующие системные вызовы, вместо этого вызывается prlimit() по причинам, описанным в разделе ДЕФЕКТЫ.

Обёрточная функция в glibc называется prlimit(); нижележащий системный вызов называется prlimit64().

## ДЕФЕКТЫ
В старых ядрах Linux сигналы SIGXCPU и SIGKILL, посылаемые когда у процесса обнаруживается достижение мягкого и жёсткого ограничения RLIMIT_CPU, доставляются на одну секунду (ЦП) позднее чем это должно быть. Это исправлено в ядре версии 2.6.8.

В ядрах 2.6.x до версии 2.6.17, ограничение RLIMIT_CPU равное 0, неправильно воспринималось как «без ограничения» (подобно RLIM_INFINITY). Начиная с Linux 2.6.17, установка ограничения в 0 действует, но реально обрабатывается как ограничение в 1 секунду.

Из-за дефекта ядра RLIMIT_RTPRIO не работает в версии 2.6.12; это исправлено в ядре 2.6.13.

В ядре 2.6.12 было несоответствие в единицу между диапазонами приоритетов, возвращаемых getpriority(2) и RLIMIT_NICE. Это приводило к тому, что реальный максимум значения nice вычислялся как 19 - rlim_cur. Исправлено в ядре 2.6.13.

Начиная с Linux 2.6.12, если процесс имеет мягкое ограничение RLIMIT_CPU и установлен обработчик для SIGXCPU, то, помимо вызова обработчика сигнала, ядро увеличивает мягкое ограничение на одну секунду. Такое поведение повторяется, если процесс продолжает потреблять процессорное время, и происходит это до тех пор, пока не будет достигнуто жёсткое ограничение, после чего процесс будет завершён. В других реализациях мягкое ограничение RLIMIT_CPU не меняется подобным образом, и поведение Linux, вероятно, нестандартно; переносимые приложения не должны полагаться на данную специфику Linux. Ограничение Linux RLIMIT_RTTIME демонстрирует такое же поведение, при исчерпании мягкого ограничения.

В ядрах до 2.4.22 не определялась ошибка EINVAL в setrlimit(), если значение rlim->rlim_cur было больше rlim->rlim_max.

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

### Представление «больших» значений ограничений ресурсов на 32-битных платформах
В обёрточных функциях glibc getrlimit() и setrlimit() используется 64-битный тип данных rlim_t, даже на 32-битных платформах. Однако в системных вызовах getrlimit() и setrlimit() тип данных rlim_t приводится к unsigned long (32-битному). Кроме этого, в ядре Linux ограничители ресурсов на 32-битных платформах представлены типом unsigned long. Однако 32-битный тип данных недостаточно велик. Для этого больше подходит RLIMIT_FSIZE, который определяет максимальный размер на который можно увеличить файл; чтобы его можно было использовать, данное ограничение должно быть представлено типом, соразмерным с типом, используемым для представления файловых смещений — 64-битным off_t (предполагается, что программа компилируется в параметром _FILE_OFFSET_BITS=64).

Если программа пытается задать ограничение ресурса значением, большим чем можно представить 32-битным unsigned long, то, чтобы обойти это ограничение ядра, обёрточная функция glibc setrlimit() просто преобразует значение ограничения в RLIM_INFINITY. Иначе говоря, запрашиваемое назначение ограничения ресурса просто игнорируется.

Начиная с версии 2.13, в glibc для обхода ограничений системных вызовов getrlimit() и setrlimit() для реализации обёрточных функций setrlimit() и getrlimit() используется вызов prlimit().

## ПРИМЕР
Представленная ниже программа показывает использование prlimit().

```
#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/resource.h>
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \

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

    struct rlimit old, new;

    struct rlimit *newp;

    pid_t pid;

    if (!(argc == 2 || argc == 4)) {

        fprintf(stderr, "Использование: %s <pid> [<новое-мягкое-ограничение> "

                "<новое-жёсткое-ограничение>]\n", argv[0]);

        exit(EXIT_FAILURE);

    }

    pid = atoi(argv[1]);        /* PID процесса назначения */

    newp = NULL;

    if (argc == 4) {

        new.rlim_cur = atoi(argv[2]);

        new.rlim_max = atoi(argv[3]);

        newp = &new;

    }

    /* Установить ограничение на время ЦП процесса назначения;

       получить и показать предыдущее ограничение */

    if (prlimit(pid, RLIMIT_CPU, newp, &old) == -1)

        errExit("prlimit-1");

    printf("Previous limits: soft=%lld; hard=%lld\n",

            (long long) old.rlim_cur, (long long) old.rlim_max);

    /* Получить и показать новое ограничение времени ЦП */

    if (prlimit(pid, RLIMIT_CPU, NULL, &old) == -1)

        errExit("prlimit-2");

    printf("Новые ограничения: мягкое=%lld; жёсткое=%lld\n",

            (long long) old.rlim_cur, (long long) old.rlim_max);

    exit(EXIT_SUCCESS);
}
```

## СМОТРИТЕ ТАКЖЕ
prlimit(1), dup(2), fcntl(2), fork(2), getrusage(2), mlock(2), mmap(2), open(2), quotactl(2), sbrk(2), shmctl(2), malloc(3), sigqueue(3), ulimit(3), core(5), capabilities(7), cgroups(7), credentials(7), signal(7)


getrusage

title: getrusage(2)

summary: считывает использованные ресурсы

text:
# getrusage(2)

## ИМЯ
getrusage - считывает использованные ресурсы

## ОБЗОР
\#include <sys/time.h>

\#include <sys/resource.h>

int getrusage(int who, struct rusage *usage);

## ОПИСАНИЕ
getrusage() возвращает текущие ограничения на ресурсы для значения who, которое может быть:

RUSAGE_SELF

Возвращает статистику по использованию ресурсов вызывающим процессом (суммируются значения всех нитей процесса).

RUSAGE_CHILDREN

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

RUSAGE_THREAD (начиная с Linux 2.6.26)

Возвращает статистику по использованию ресурсов вызывающей нити. Чтобы получить определение этой константы из <sys/resource.h> должен быть определён макрос тестирования свойств _GNU_SOURCE (до включения всех заголовочных файлов).

Данные по использованным ресурсам возвращаются в структуре, на которую указывает usage; она имеет следующий вид:

```
struct rusage {

    struct timeval ru_utime; /* время ЦП, исполь. в режиме пользователя */

    struct timeval ru_stime; /* время ЦП, исполь. в режиме системы */

    long   ru_maxrss;        /* максимальный rss */

    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;        /* количество посланных сообщений IPC */

    long   ru_msgrcv;        /* количество принятых сообщений IPC */

    long   ru_nsignals;      /* количество принятых сигналов */

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

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

Не все поля заполняются; несопровождаемые поля устанавливаются ядром в ноль. (Несопровождаемые поля предоставляются для совместимости с другими системами, и когда-нибудь станут поддерживаться в Linux.) Поля следует понимать так:

ru_utime

Общее количество времени, проведённое в режиме пользователя, выражается структурой timeval (секунды и микросекунды).

ru_stime

Общее количество времени, проведённое в режиме ядра, выражается структурой timeval (секунды и микросекунды).

ru_maxrss (начиная с Linux 2.6.32)

Максимальный используемый размер постоянно занимаемый в памяти (в килобайтах). Для RUSAGE_CHILDREN определяется наибольший размер постоянной памяти среди потомков, а не максимальный размер постоянной памяти всего дерева процесса.

ru_ixrss (не ведётся)

В настоящее время в Linux не учитывается.

ru_idrss (не ведётся)

В настоящее время в Linux не учитывается.

ru_isrss (не ведётся)

В настоящее время в Linux не учитывается.

ru_minflt

Количество сбойных страниц, обслуженных без операций ввода-вывода; в данном случае страницы «восстановлены» из списка страниц, ожидающих перемещения.

ru_majflt

Количество сбойных страниц, обслуженных с помощью операций ввода-вывода.

ru_nswap (не ведётся)

В настоящее время в Linux не учитывается.

ru_inblock (начиная с Linux 2.6.22)

Количество обращений на чтение из файловой системы.

ru_oublock (начиная с Linux 2.6.22)

Количество обращений на запись в файловую систему.

ru_msgsnd (не ведётся)

В настоящее время в Linux не учитывается.

ru_msgrcv (не ведётся)

В настоящее время в Linux не учитывается.

ru_nsignals (не ведётся)

В настоящее время в Linux не учитывается.

ru_nvcsw (начиная с Linux 2.6)

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

ru_nivcsw (начиная с Linux 2.6)

Количество переключений контекста в следствии вытеснения процессом с более высоким приоритетом или из-за истечения рабочего временного интервала процесса.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении возвращается 0. В случае ошибки возвращается -1, а errno устанавливается в соответствующее значение.

## ОШИБКИ
EFAULT

usage указывает за пределы доступного адресного пространства.

EINVAL

Неверное значение who.

## АТРИБУТЫ
Описание терминов данного раздела смотрите в attributes(7).

Интерфейс

Атрибут

Значение

getrusage()

Безвредность в нитях

MT-Safe

## СООТВЕТСТВИЕ СТАНДАРТАМ
POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD. В POSIX.1 определён вызов getrusage(), но указаны только поля ru_utime и ru_stime.

RUSAGE_THREAD есть только в Linux.

## ЗАМЕЧАНИЯ
Значения использованных ресурсов сохраняются при execve(2).

Включать <sys/time.h> в настоящее время не требуется, но это увеличивает переносимость. (Хотя struct timeval определена в <sys/time.h>.)

В ядрах Linux до версии 2.6.9, если значение SIGCHLD равно SIG_IGN, то использованные ресурсы потомков процессов автоматически включаются в значение, возвращаемое RUSAGE_CHILDREN, хотя в POSIX.1-2001 это явно запрещено. Это несоответствие исправлено в Linux 2.6.9 и более новых версиях.

Определение структуры, показанное в начале страницы, взято из 4.3BSD Reno.

В старых системах была функция vtimes() с подобным getrusage() назначением. Для обратной совместимости в glibc также есть функция vtimes(). Во всех новых приложениях должен быть использован getrusage().

Смотрите также описание /proc/[pid]/stat в proc(5).

## СМОТРИТЕ ТАКЖЕ
clock_gettime(2), getrlimit(2), times(2), wait(2), wait4(2), clock(3)


getsid

title: getsid(2)

summary: получить ID сеанса

text:
# getsid(2)

## ИМЯ
getsid - получить ID сеанса

## ОБЗОР
\#include <sys/types.h>

\#include <unistd.h>

pid_t getsid(pid_t pid);

Требования макроса тестирования свойств для glibc (см. feature_test_macros(7)):

getsid():

_XOPEN_SOURCE >= 500

|| /* начиная с glibc 2.12: */ _POSIX_C_SOURCE >= 200809L

## ОПИСАНИЕ
Вызов getsid(0) возвращает идентификатор (ID) сеанса вызвавшего процесса. Вызов getsid() возвращает идентификатор сеанса процесса с ID равным pid. Если pid равно 0, то getsid() возвращает идентификатор сеанса вызвавшего процесса.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении возвращается идентификатор сеанса. В случае ошибки возвращается (pid_t) -1, а errno устанавливается в соответствующее значение.

## ОШИБКИ
EPERM

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

ESRCH

Процесс с идентификатором pid не найден.

## ВЕРСИИ
Данный системный вызов доступен в Linux начиная с версии 2.0.

## СООТВЕТСТВИЕ СТАНДАРТАМ
POSIX.1-2001, POSIX.1-2008, SVr4.

## ЗАМЕЧАНИЯ
Linux не возвращает EPERM.

На странице credentials(7) есть описание сеансов и их идентификаторов.

## СМОТРИТЕ ТАКЖЕ
getpgid(2), setsid(2), credentials(7)


getsockname

title: getsockname(2)

summary: получить имя сокета

text:
# getsockname(2)

## ИМЯ
getsockname - получить имя сокета

## ОБЗОР

```
#include <sys/socket.h>
```

```
int getsockname(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
```

## ОПИСАНИЕ
getsockname() возвращает текущий адрес, к которому привязан сокет sockfd, в буфере, указываемом addr. В параметре addrlen должно быть указано, сколько места выделено (в байтах), на которое указывает addr. При возврате в этом параметре передается реальный размер адреса сокета.

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

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении возвращается 0. В случае ошибки возвращается -1, а errno устанавливается в соответствующее значение.

## ОШИБКИ
EBADF

Аргумент sockfd не является допустимым файловым дескриптором.

EFAULT

Аргумент addr указывает на память в недопустимой части адресуемого пространства процесса.

EINVAL

Неправильное значение аргумента addrlen (например, отрицательное).

ENOBUFS

Недостаточно ресурсов в системе для выполнения операции.

ENOTSOCK

Файловый дескриптор sockfd указывает не на каталог.

## СООТВЕТСТВИЕ СТАНДАРТАМ
POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD, (getsockname() впервые появился в 4.2BSD).

## ЗАМЕЧАНИЯ
Описание типа socklen_t смотрите в accept(2).

## СМОТРИТЕ ТАКЖЕ
bind(2), socket(2), getifaddrs(3), ip(7), socket(7), unix(7)


getsockopt

title: getsockopt(2)

summary: получить или установить флаги сокета

text:
# getsockopt(2)

## ИМЯ
getsockopt, setsockopt - получить или установить флаги сокета

## ОБЗОР

```
#include <sys/types.h>          /* смотрите ЗАМЕЧАНИЯ */
#include <sys/socket.h>
```

```
int getsockopt(int sockfd, int level, int optname,
               void *optval, socklen_t *optlen);
int setsockopt(int sockfd, int level, int optname,
               const void *optval, socklen_t optlen);
```

## ОПИСАНИЕ
getsockopt() и setsockopt() управляют параметрами сокета, на который указывает файловый дескриптор sockfd. Параметры могут быть из различных уровней протоколов; они всегда присутствуют на самом верхнем уровне сокета.

При работе с параметрами сокета должен быть указан уровень, на котором находится этот параметр и его имя. Для работы с параметрами на уровне API сокета в level указывается значение SOL_SOCKET. Для работы с параметрами на любом другом уровне, этим вызовам передаётся номер соответствующего протокола, который они контролируют. Например, для указания, что параметр должен интерпретироваться протоколом TCP, в level нужно указать номер протокола TCP; смотрите getprotoent(3).

Аргументы optval и optlen используются в setsockopt() для доступа к значениям параметров. Для getsockopt() они задают буфер, в который нужно поместить запрошенное значение параметра при возврате. У getsockopt() в аргументе optlen изначально содержится размер буфера, на который указывает optval, а при завершении в нём содержится реальный размер возвращаемого значения. Если значение параметра не указывается или возвращается, то optval может быть NULL.

Аргумент optname и все указанные параметры без изменений передаются для интерпретации соответствующему модулю протоколов. Файл <sys/socket.h> содержит определения параметров уровня сокета; их описание дано ниже. Параметры на других уровнях протоколов различаются по формату и по имени. Обращайтесь к соответствующим файлам раздела 4 справочных страниц.

Большинство параметров уровня сокета используют тип int для аргумента optval. Чтобы установить параметр логического типа аргумент setsockopt() должен быть ненулевым, и ноль, если нужно отключить этот параметр.

Описание доступных параметров сокетов находится в socket(7) и соответствующих протоколам справочных страницах.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении при стандартных параметрах возвращается 0. В случае ошибки возвращается -1, а errno устанавливается в соответствующее значение.

Netfilter позволяет программисту определять собственные параметры сокетов со привязанными обработчиками; для таких параметров при успешном выполнении возвращается значение, полученное от обработчика.

## ОШИБКИ
EBADF

Аргумент sockfd не является допустимым файловым дескриптором.

EFAULT

Адрес, на который указывает optval, не находится в разрешённой части адресного пространства процесса. Для getsockopt() эта ошибка может также появиться, если optlen выходит за пределы адресного пространства процесса.

EINVAL

Неправильное значение optlen в setsockopt(). В некоторых случаях эта ошибка может возникать из-за неправильного значения в optval (например, для параметра IP_ADD_MEMBERSHIP, описанного в ip(7)).

ENOPROTOOPT

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

ENOTSOCK

Файловый дескриптор sockfd указывает не на каталог.

## СООТВЕТСТВИЕ СТАНДАРТАМ
POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD (данные системные вызовы впервые появились в 4.2BSD).

## ЗАМЕЧАНИЯ
В POSIX.1 не требуется включение <sys/types.h>, и этот заголовочный файл не требуется в Linux. Однако, для некоторых старых реализаций (BSD) требует данный файл, и в переносимых приложениях для предосторожности, вероятно, лучше его указать.

Описание типа socklen_t смотрите в accept(2).

## ДЕФЕКТЫ
Некоторые параметры сокетов должны обрабатываться на более низких уровнях системы.

## СМОТРИТЕ ТАКЖЕ
ioctl(2), socket(2), getprotoent(3), protocols(5), ip(7), packet(7), socket(7), tcp(7), udp(7), unix(7)


gettid

title: gettid(2)

summary: получить идентификатор нити

text:
# gettid(2)

## ИМЯ
gettid - получить идентификатор нити

## ОБЗОР

```
#include <sys/types.h>
```

```
pid_t gettid(void);
```

## ОПИСАНИЕ
gettid() возвращает идентификатор нити вызвавшего процесса (TID). В случае процесса с одной нитью он эквивалентен идентификатору процесса (PID, возвращаемому getpid(2)). В случае процесса с множеством нитей все нити имеют одинаковый идентификатор процесса PID, но каждый из них имеет уникальный идентификатор нити TID. Для получения подробной информации см. обсуждение CLONE_THREAD clone(2).

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении возвращается идентификатор вызывающей нити.

## ОШИБКИ
Этот системный вызов всегда выполняется успешно.

## ВЕРСИИ
Системный вызов gettid() впервые появился в ядре Linux 2.4.11. Библиотечная поддержка добавлена в glibc 2.30. (ранние версии glibc не содержали обёрточную функцию для этого вызова, нужно было использовать syscall(2)).

## СООТВЕТСТВИЕ СТАНДАРТАМ
Вызов gettid() является специфичным для Linux и не должен использоваться в переносимых программах.

## ЗАМЕЧАНИЯ
Идентификатор нити, возвращаемый этим вызовом, не является идентификатором нити POSIX (т.е., значением с произвольной структурой, возвращаемым pthread_self(3)).

В новой группе нитей, созданной вызовом clone(2) без флага CLONE_THREAD (или новый процесс, созданный fork(2)), новый процесс является лидером группы нитей, и ID этой группы нитей (значение, возвращаемое getpid(2)) совпадает с ID этой нити (значение, возвращаемое gettid()).

## СМОТРИТЕ ТАКЖЕ
capget(2), clone(2), fcntl(2), fork(2), getpid(2), get_robust_list(2), ioprio_set(2), perf_event_open(2), sched_setaffinity(2), sched_setparam(2), sched_setscheduler(2), tgkill(2), timer_create(2)


gettimeofday

title: gettimeofday(2)

summary: получает/устанавливает время

text:
# gettimeofday(2)

## ИМЯ
gettimeofday, settimeofday - получает/устанавливает время

## ОБЗОР

```
#include <sys/time.h>
```

```
int gettimeofday(struct timeval *tv, struct timezone *tz);
```

```
int settimeofday(const struct timeval *tv, const struct timezone *tz);
```

Требования макроса тестирования свойств для glibc (см. feature_test_macros(7)):

settimeofday():

начиная с glibc 2.19:

_DEFAULT_SOURCE

в glibc 2.19 и старее:

_BSD_SOURCE

## ОПИСАНИЕ
Функция gettimeofday() и settimeofday() позволяют получить и задать время, а также часовой пояс. Аргумент tv имеет тип struct timeval (определён в <sys/time.h>):

```
struct timeval {

    time_t      tv_sec;     /* секунды */

    suseconds_t tv_usec;    /* микросекунды */
};
```

и задаёт количество секунд и микросекунд, прошедших с начала эпохи (см. time(2)). Аргумент tz имеет тип struct timezone:

```
struct timezone {

    int tz_minuteswest;     /* количество минут западнее Гринвича */

    int tz_dsttime;         /* тип корректировки DST */
};
```

Если tv или tz имеют значение NULL, то соответствующая структура не задана и не будет возвращена (однако при компиляции будут выдаваться предупреждения, если tv равно NULL).

Пользоваться структурой timezone не рекомендуется; значением аргумента tz в большинстве случаев должен быть NULL (см. ЗАМЕЧАНИЯ далее).

В Linux существует специфическое понятие «временной сдвиг» (warp clock), связанное с системным вызовом settimeofday(), который образуется при самом первом вызове (после загрузки), если аргумент tz не равен NULL, аргумент tv равен NULL и поле tz_minuteswest не равно нулю (в этом случае значение поля tz_dsttime должно быть равно нулю). В этом случае предполагается, что время аппаратных часов (CMOS clock) местное и к нему должен быть добавлен этот параметр для того, чтобы получилось время UTC. Но, как мы и говорили, использовать этот метод не рекомендуется.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении gettimeofday() и settimeofday() возвращают 0, или -1 в случае ошибки (errno устанавливается в соответствующее значение).

## ОШИБКИ
EFAULT

Одно из значений в tv или tz находится вне доступного адресного пространства.

EINVAL

(settimeofday()): неверное значение timezone.

EINVAL

(settimeofday()): tv.tv_sec отрицательно или tv.tv_usec вне диапазона [0..999,999].

EINVAL (начиная с Linux 4.3)

(settimeofday()): выполнялась попытка установки времени в значение меньше текущего значения часов CLOCK_MONOTONIC (смотрите clock_gettime(2)).

EPERM

У вызывающего процесса недостаточно прав для вызова settimeofday(); в Linux для этого требуется мандат CAP_SYS_TIME.

## СООТВЕТСТВИЕ СТАНДАРТАМ
SVr4, 4.3BSD. В POSIX.1-2001 описан gettimeofday(), но нет settimeofday(). В POSIX.1-2008 вызов gettimeofday() помечен как устаревший, вместо него рекомендуется использовать clock_gettime(2).

## ЗАМЕЧАНИЯ
На время, возвращаемое gettimeofday(), влияют скачки в системном времени (например, если системный администратор вручную изменил системное время). Если вам требуются однообразно увеличивающееся время, смотрите clock_gettime(2).

Для работы со структурой timeval существуют макросы, описанные в timeradd(3).

Обычно, поля struct timeval имеют тип long.

### Отличия между библиотекой C и ядром
На некоторых архитектурах реализация gettimeofday() находится в vdso(7).

### Поле tz_dsttime
В системах с не ядрами Linux, но с glibc, полю tz_dsttime из struct timezone вызов gettimeofday() присвоит ненулевое значение, если в текущем часовом поясе уже применялось или будет применяться правило перехода на летнее время. В этом смысле это зеркально отражает назначение daylight(3) для текущего пояса. В Linux с glibc значение поля tz_dsttime из struct timezone никогда не используется в settimeofday() или gettimeofday(). Таким образом, следующий абзац представляет только исторический интерес.

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

```
DST_NONE     /* нет DST */
DST_USA      /* американский DST */
DST_AUST     /* австралийский DST */
DST_WET      /* западноевропейский DST */
DST_MET      /* средневосточный DST */
DST_EET      /* восточноевропейский DST */
DST_CAN      /* Канада */
DST_GB       /* Великобритания и Ирландия */
DST_RUM      /* Румыния */
DST_TUR      /* Турция */
DST_AUSTALT  /* австралийский со сдвигом на 1986 год */
```

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

## СМОТРИТЕ ТАКЖЕ
date(1), adjtimex(2), clock_gettime(2), time(2), ctime(3), ftime(3), timeradd(3), capabilities(7), time(7), vdso(7), hwclock(8)


getuid

title: getuid(2)

summary: получить идентификатор пользователя

text:
# getuid(2)

## ИМЯ
getuid, geteuid - получить идентификатор пользователя

## ОБЗОР
\#include <unistd.h>

\#include <sys/types.h>

uid_t getuid(void);

uid_t geteuid(void);

## ОПИСАНИЕ
getuid() возвращает фактический идентификатор (ID) пользователя вызывающего процесса.

geteuid() возвращает эффективный идентификатор пользователя вызывающего процесса.

## ОШИБКИ
Функции всегда завершаются успешно.

## СООТВЕТСТВИЕ СТАНДАРТАМ
POSIX.1-2001, POSIX.1-2008, 4.3BSD.

## ЗАМЕЧАНИЯ

### История
В UNIX V6 вызов getuid() возвращал (euid << 8) + uid. В UNIX V7 появились отдельные вызовы getuid() и geteuid().

Первоначальные версии системных вызовов getuid() и geteuid() в Linux поддерживали только 16-битные идентификаторы пользователей и групп. Позднее в Linux 2.4 были добавлены вызовы getuid32() и geteuid32(), поддерживающие 32-битные идентификаторы. В glibc обёрточные функции getuid() и geteuid() работают одинаково вне зависимости от версий ядра.

На Alpha вместо пары системных вызовов getuid() и geteuid() предоставляется один getxuid(), который возвращает пару реальный и эффективный UID. Обёрточные функции glibc getuid() и geteuid() скрывают это. Подробности об отображении регистров смотрите в syscall(2).

## СМОТРИТЕ ТАКЖЕ
getresuid(2), setreuid(2), setuid(2), credentials(7)


getunwind

title: getunwind(2)

text:
# getunwind(2)

## ИМЯ
getunwind - копирует раскрученные данные в буфер вызывающего

## ОБЗОР

```
#include <syscall.h>
#include <linux/unwind.h>
```

```
long getunwind(void *buf, size_t buf_size);
```

Замечание: в glibc нет обёрточной функции для данного системного вызова; смотрите ЗАМЕЧАНИЯ.

## ОПИСАНИЕ
Замечание: этот вызов устарел.

Специальный системный вызов getunwind() для IA-64 копирует раскрученные данные кадра вызова ядра в буфер, указанный в buf, и возвращает размер раскрученных данных; эти данные описывают шлюзовую страницу (gate page, код ядра, который отображается в адресное пространство пользователя).

Размер буфера buf задаётся в buf_size. Данные копируются только, если значение buf_size больше или равно размеру раскрученных данных и значение buf не равно NULL; в противном случае, данные не копируются и вызов завершается без ошибки, возвращая размер, который необходим для хранения раскрученных данных.

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

```
u64 start;    (64-битный адрес начала функции)
u64 end;      (64-битный адрес конца функции)
u64 info;     (смещение относительно BUF на раскрученную информацию)
```

Запись, у которой значение start равно нулю, указывает на конец таблицы. Подробности формата смотрите в руководстве IA-64 Software Conventions and Runtime Architecture.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении getunwind() возвращает размер раскрученных данных. При ошибке возвращается -1, а в errno задаётся причина ошибки.

## ОШИБКИ
Вызов getunwind() завершается с ошибкой EFAULT, если раскрученную информацию невозможно сохранить в пространство, указанное buf.

## ВЕРСИИ
Данный системный вызов доступен в Linux начиная с версии 2.4.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Данный системный вызов есть только в Linux и доступен только на архитектуре IA-64.

## ЗАМЕЧАНИЯ
Данный системный вызов устарел. Современным способом получить раскрученные данные ядра является работа через vdso(7).

В glibc нет обёрточной функции для данного системного вызова; в маловероятном случае, когда вам нужно использовать его, используйте syscall(2).

## СМОТРИТЕ ТАКЖЕ
getauxval(3)


getxattr

title: getxattr(2)

summary: получить расширенное значение атрибута

text:
# getxattr(2)

## ИМЯ
getxattr, lgetxattr, fgetxattr - получить расширенное значение атрибута

## ОБЗОР

```
#include <sys/types.h>
#include <sys/xattr.h>
```

```
ssize_t getxattr(const char *path, const char *name,
                 void *value, size_t size);
ssize_t lgetxattr(const char *path, const char *name,
                 void *value, size_t size);
ssize_t fgetxattr(int fd, const char *name,
                 void *value, size_t size);
```

## ОПИСАНИЕ
Расширенные атрибуты представляют собой пару имя:значение и связываются с записями inode (файлы, каталоги, символьные ссылки и т.п.). Они являются расширениями к обычным атрибутам, связанным со всеми записями inode в системе (например, данные stat(2)). Полное описание модели расширенных атрибутов можно найти в xattr(7).

getxattr() возвращает значение расширенного атрибута с именем name и связанного с указанным путем path в файловой системе. Значение атрибута помещается в буфер, указанный в value; в size задаётся размер этого буфера. В качестве возвращаемого значения вызова возвращается количество байт, помещённых в value.

lgetxattr() идентичен getxattr(), за исключением указания символьной ссылки, когда рассматривается именно ссылка, а не файл, на который она указывает.

fgetxattr() идентичен getxattr(), только вместо path берётся открытый файл, на который указывает fd (возвращаемый open(2)).

Расширенный атрибут name является строкой, заканчивающейся null. Имя включает префикс пространства имён; их может быть несколько, разрозненные пространства связаны с разными записями inode. Значением расширенного атрибута является произвольный кусок текстовых или двоичных данных, который был назначен с помощью setxattr(2).

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

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении эти вызовы возвращают неотрицательное число, обозначающее размер (в байтах) значения расширенного атрибута. При ошибке возвращается -1 и errno устанавливается в соответствующее значение.

## ОШИБКИ
E2BIG

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

ENODATA

Атрибут с таким именем не существует или процесс не имеет доступа к этому атрибуту.

ENOTSUP

Расширенные атрибуты не поддерживаются файловой системой или отключены.

ERANGE

Размер size буфера value слишком мал для хранения результата.

Также могут возникать ошибки, описанные в stat(2).

## ВЕРСИИ
Данные системные вызовы доступны в Linux начиная с ядра версии 2.4; поддержка в glibc появилась в версии 2.3.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Данные системные вызовы есть только в Linux.

## ПРИМЕР
Смотрите listxattr(2).

## СМОТРИТЕ ТАКЖЕ
getfattr(1), setfattr(1), listxattr(2), open(2), removexattr(2), setxattr(2), stat(2), symlink(7), xattr(7)


idle

title: idle(2)

summary: переводит процесс 0 в режим бездействия

text:
# idle(2)

## ИМЯ
idle - переводит процесс 0 в режим бездействия

## ОБЗОР
\#include <unistd.h>

int idle(void);

## ОПИСАНИЕ
idle() — это внутренний системный вызов, используемый во время начальной загрузки. Он помечает страницы процесса как выгружаемые в пространство подкачки, снижает его приоритет и входит в основной цикл планирования. idle() никогда не возвращает управление.

Только процесс 0 может вызывать idle(). Все пользовательские процессы, даже процессы с правами суперпользователя, будут получать EPERM.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
idle() никогда не возвращается в процесс 0 и всегда возвращает -1 для пользовательских процессов.

## ОШИБКИ
EPERM

Всегда для пользовательского процесса.

## ВЕРСИИ
Начиная с Linux 2.3.13 этот системный вызов больше не существует.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Данная функция есть только в Linux и не должна использоваться в программах, которые задуманы как переносимые.


title: init_module(2)

summary: загружает модуль ядра

text:
# init_module(2)

## ИМЯ
init_module, finit_module - загружает модуль ядра

## ОБЗОР

```
int init_module(void *module_image, unsigned long len,
                const char *param_values);
```

```
int finit_module(int fd, const char *param_values,
                 int flags);
```

Замечание: В заголовочных файлах glibc отсутствует init_module() и finit_module(); смотрите ЗАМЕЧАНИЯ.

## ОПИСАНИЕ
Вызов init_module() загружает образ ELF в пространство ядра, выполняет все необходимые перемещения символов, инициализирует значения параметров модуля, предоставленные вызывающим и запускает функцию модуля init. Данный системный вызов требует дополнительных прав.

Аргумент module_image указывает на буфер, содержащий двоичный образ для загрузки; в len задаётся размер этого буфера. Образ модуля должен быть корректным образом в формате ELF, собранным для работающего в данный момент ядра.

Значением param_values является строка, содержащая значения параметров модуля (через пробел), определённых в модуле через module_param() и module_param_array(). Ядро обрабатывает эту строку и инициализирует указанные параметры. Каждый параметр имеет вид:

имя[=значение[,значение…]]

Параметр имя — один из определённых параметров модуля с помощью module_param() (смотрите файл исходного кода ядра Linux include/linux/moduleparam.h). Параметр значение не обязателен в случае параметров с типом bool и invbool. Значение массива параметров указываются через запятую.

### finit_module()
Системный вызов finit_module() подобен init_module(), но читает модуль для загрузки из файлового дескриптора fd. Он полезен, если подлинность модуля ядра можно определить по его расположению в файловой системе; в таких случаях затрат на использование криптографически подписанных модулей для определения подлинности модуля можно избежать. Аргумент param_values такой же как у init_module().

Аргумент flags изменяет выполнение finit_module(). Это битовая маска, создаваемая объединением нуля или более следующих флагов:

MODULE_INIT_IGNORE_MODVERSIONS

Игнорировать хэши версий символов.

MODULE_INIT_IGNORE_VERMAGIC

Игнорировать версию ядра.

Есть несколько элементов, встроенных в модуль, которые позволяют убедиться, что модуль подходит для загрузки в ядро. Эти элементы записываются в модуль на этапе сборки и проверяются при загрузке ядра. Во-первых, модуль имеет строку «vermagic», содержащую номер версии ядра и основные свойства (такие как тип ЦП). Во-вторых, если модуль собран с включённым параметром настройки CONFIG_MODVERSIONS, то он содержит хэш версии для каждого используемого модулем символа. Данный хэш основан на типе аргумента и возвращаемом значении функции с именем символа. В этом случае номер версии ядра в строке «vermagic» игнорируется, так как считается, что хэши версий символов достаточно надёжны.

Использование флага MODULE_INIT_IGNORE_VERMAGIC требует игнорировать строку «vermagic», а флаг MODULE_INIT_IGNORE_MODVERSIONS требует игнорировать хэши версий символов. Если ядро собрано с разрешением принудительной загрузки (параметр настройки CONFIG_MODULE_FORCE_LOAD), то загрузка продолжается, в противном случае она завершается ошибкой ENOEXEC, как и ожидается для некорректных модулей.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении возвращается 0. В случае ошибки возвращается -1, а errno устанавливается в соответствующее значение.

## ОШИБКИ
EBADMSG (начиная с Linux 3.7)

Неправильный формат подписи модуля.

EBUSY

Истекло время ожидания попытки определения символьной ссылки данным модулем.

EFAULT

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

ENOKEY (начиная с Linux 3.7)

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

ENOMEM

Не хватает памяти.

EPERM

Вызывающий не имеет прав (не имеет мандата CAP_SYS_MODULE), или отключена загрузка модулей (смотрите /proc/sys/kernel/modules_disabled в proc(5)).

Дополнительно в init_module() могут возникать следующие ошибки:

EEXIST

Модуль с таким именем уже загружен.

EINVAL

Некорректное значение param_values, или какая-то часть образа ELF в module_image содержит противоречивую информацию.

ENOEXEC

Двоичный образ, переданный module_image, не является образом ELF, или образ ELF некорректный или для другой архитектуры.

Дополнительно в finit_module() могут возникать следующие ошибки:

EBADF

Файл, на который ссылается fd, не открыт для чтения.

EFBIG

Файл, на который ссылается fd, слишком большой.

EINVAL

Значение flags неверно.

ENOEXEC

Значение fd не указывает на открытый файл.

Дополнительно к этим ошибкам, если функция модуля init при выполнении возвратила ошибку, то init_module() или finit_module() завершается с ошибкой и в errno записывается значение, полученное от функции init.

## ВЕРСИИ
Вызовы finit_module() доступен в Linux, начиная с версии 3.8.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Вызовы init_module() и finit_module() есть только в Linux.

## ЗАМЕЧАНИЯ
Системный вызов init_module() не поддерживается glibc. В заголовочных файлах glibc он не объявлен, но в недавнем прошлом glibc до версии 2.23 экспортировал ABI для этого системного вызова. Поэтому чтобы получить данный системный вызов достаточно вручную объявить интерфейс в своём коде; или же вы можете вызвать его через syscall(2).

В glibc нет обёртки для finit_module(); запускайте его с помощью syscall(2).

Информацию по уже загруженным модулями можно найти в файле /proc/modules и в соответствующем каждому модулю подкаталогу в /sys/module.

Дополнительную информацию смотрите в файле include/linux/module.h из исходного кода ядра Linux.

### Linux версии 2.4 и более ранние
В Linux версии 2.4 и более ранних системный вызов init_module() был немного другим:

\#include <linux/module.h>

int init_module(const char *name, struct module *image);

(Приложения пользовательского пространства могут определить какая из версий init_module() доступна, вызвав query_module(); этот вызов завершается ошибкой ENOSYS в Linux 2.6 и более новых.)

Старая версия системного вызова загружает перемещённый образ модуля image, в пространство ядра и выполняет функцию модуля init. Вызывающий должен предоставить перемещённый образ (начиная с Linux 2.6, системный вызов init_module() сам делает перемещение).

Образ модуля начинается со структуры модуля, за которой следует код и данные. Начиная с Linux 2.2 структура модуля определена следующим образом:

```
struct module {

    unsigned long         size_of_struct;

    struct module        *next;

    const char           *name;

    unsigned long         size;

    long                  usecount;

    unsigned long         flags;

    unsigned int          nsyms;

    unsigned int          ndeps;

    struct module_symbol *syms;

    struct module_ref    *deps;

    struct module_ref    *refs;

    int                 (*init)(void);

    void                (*cleanup)(void);

    const struct exception_table_entry *ex_table_start;

    const struct exception_table_entry *ex_table_end;
#ifdef __alpha__

    unsigned long gp;
#endif
};
```

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

## СМОТРИТЕ ТАКЖЕ
create_module(2), delete_module(2), query_module(2), lsmod(8), modprobe(8)


title: inotify_add_watch(2)

text:
# inotify_add_watch(2)

## ИМЯ
inotify_add_watch - добавляет сторожок к инициализированному экземпляру inotify

## ОБЗОР
\#include <sys/inotify.h>

int inotify_add_watch(int fd, const char *pathname, uint32_t mask);

## ОПИСАНИЕ
Вызов inotify_add_watch() добавляет новый сторожок (watch) или изменяет существующий, для файла, чьё расположение указано в pathname; вызывающий должен иметь право читать этот файл. Аргумент fd является файловым дескриптором, ссылающимся на экземпляр inotify, у которого изменяется список сторожков. Отслеживаемые с pathname события указываются маской битов в аргументе mask. Описание битов mask смотрите в inotify(7).

При успешном выполнении inotify_add_watch() возвращает уникальный дескриптор сторожка данного экземпляра inotify, для объекта файловой системы (иноды), связанной с pathname. Если ранее объект файловой системы не наблюдался данным экземпляром inotify, то создаётся новый дескриптор сторожка. Если объект файловой системы уже отслеживался (возможно, через другую ссылку на тот же объект), то возвращается дескриптор существующего сторожка.

Дескриптор сторожка возвращается при последующих операциях read(2) из файлового дескриптора inotify. При чтении извлекаются структуры inotify_event (см. inotify(7)), указывающие на события в файловой системе; дескриптор сторожка внутри этой структуры определяет объект, для которого произошло событие.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении inotify_add_watch() возвращает неотрицательный дескриптор сторожка. При ошибке возвращается -1, а значение errno устанавливается соответствующим образом.

## ОШИБКИ
EACCES

Нет прав на чтение указанного файла.

EBADF

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

EEXIST

В mask содержится IN_MASK_CREATE и pathname ссылается на файл, который уже отслеживается тем же fd.

EFAULT

pathname указывает за пределы доступного адресного пространства.

EINVAL

Указанная маска событий не содержит допустимых событий; mask содержит IN_MASK_ADD и IN_MASK_CREATE одновременно; fd не является файловым дескриптором inotify.

ENAMETOOLONG

Слишком длинное значение аргумента pathname.

ENOENT

Один из каталогов в pathname не существует или является повисшей символьной ссылкой.

ENOMEM

Недостаточное количество памяти ядра.

ENOSPC

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

ENOTDIR

В значении mask содержится IN_ONLYDIR и pathname не является каталогом.

## ВЕРСИИ
Inotify был добавлен в ядро Linux версии 2.6.13.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Данный вызов есть только в Linux.

## СМОТРИТЕ ТАКЖЕ
inotify_init(2), inotify_rm_watch(2), inotify(7)


title: inotify_init(2)

summary: инициализирует экземпляр inotify

text:
# inotify_init(2)

## ИМЯ
inotify_init, inotify_init1 - инициализирует экземпляр inotify

## ОБЗОР

```
#include <sys/inotify.h>
```

```
int inotify_init(void);
int inotify_init1(int flags);
```

## ОПИСАНИЕ
Обзор программного интерфейса inotify смотрите в inotify(7).

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

Если flags равен 0, то inotify_init1() выполняет тоже, что и inotify_init(). Чтобы получить другое поведение, следующие значения могут быть сложены с помощью побитового ИЛИ в flags:

IN_NONBLOCK

Устанавливает флаг состояния файла O_NONBLOCK для нового открытого файлового описания (смотрите open(2)), на которое ссылается новый файловый дескриптор. Использование данного флага делает ненужными дополнительные вызовы fcntl(2) для достижения того же результата.

IN_CLOEXEC

Устанавливает флаг close-on-exec (FD_CLOEXEC) для нового открытого файлового дескриптора. Смотрите описание флага O_CLOEXEC в open(2) для того, чтобы узнать как это может пригодиться.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении данные системные вызовы возвращают новый файловый дескриптор. При ошибке возвращается -1 и errno устанавливается в соответствующее значение.

## ОШИБКИ
EINVAL

(inotify_init1()) Указано неверное значение в flags.

EMFILE

Достигнуто максимальное количество экземпляров inotify доступных пользователю.

EMFILE

Было достигнуто ограничение по количеству открытых файловых дескрипторов на процесс.

ENFILE

Достигнуто максимальное количество открытых файлов в системе.

ENOMEM

Не хватает памяти ядра.

## ВЕРСИИ
Системный вызов inotify_init() впервые появился в Linux 2.6.13; поддержка в glibc доступна с версии 2.4. Системный вызов inotify_init1() был добавлен в Linux 2.6.27; поддержка в glibc доступна с версии 2.9.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Данные системные вызовы есть только в Linux.

## СМОТРИТЕ ТАКЖЕ
inotify_add_watch(2), inotify_rm_watch(2), inotify(7)


title: inotify_rm_watch(2)

text:
# inotify_rm_watch(2)

## ИМЯ
inotify_rm_watch - удаляет существующий сторожок из экземпляра inotify

## ОБЗОР
\#include <sys/inotify.h>

int inotify_rm_watch(int fd, int wd);

## ОПИСАНИЕ
Вызов inotify_rm_watch() удаляет сторожок (watch), связанный с дескриптором сторожка wd из экземпляра inotify, связанного с файловым дескриптором fd.

Удаление сторожка приводит к созданию события IN_IGNORED для этого дескриптора сторожка (см. inotify(7)).

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении inotify_rm_watch() возвращается ноль. При ошибке возвращается -1, а в errno содержится код ошибки.

## ОШИБКИ
EBADF

Значение fd не является правильным файловым дескриптором.

EINVAL

Неправильный дескриптор сторожка wd; или fd не является файловым дескриптором inotify.

## ВЕРСИИ
Inotify был добавлен в ядро Linux версии 2.6.13.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Данный вызов есть только в Linux.

## СМОТРИТЕ ТАКЖЕ
inotify_add_watch(2), inotify_init(2), inotify(7)


intro

title: intro(2)

summary: введение в системные вызовы

text:
# intro(2)

## ИМЯ
intro - введение в системные вызовы

## ОПИСАНИЕ
В разделе 2 описываются системные вызовы Linux. Системный вызов — это точка входа в ядро Linux. Обычно, системные вызовы не запускаются напрямую, вместо этого почти все системные вызовы имеют соответствующие обёрточные функции в библиотеке C, которая выполняет некоторые действия (например, подготовку к работе в режиме ядра) для запуска системного вызова. Таким образом, работа с системным вызовом выглядит также как вызов обычной библиотечной функции.

Во многих случаях обёрточная функция библиотеки C делает не более чем:

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

- передаёт управление в режим ядра в место, где ядро выполняет всю работу системным вызовом;

- изменяет errno, если системный вызов вернул номер ошибки при возврате ядром ЦП в пользовательский режим.

Однако в некоторых случаях обёрточная функция может делать дополнительную работу, например, выполнять предварительную обработку аргументов до перехода в режим ядра и обработку значений, полученных от системного вызова. В этом случае в справочных страницах раздела 2, обычно, приводятся подробности программного интерфейса библиотеки C (обычно GNU) и системного вызова. Чаще всего, в главном ОПИСАНИИ даётся интерфейс библиотеки C, а отличия системного вызова приводятся в разделе ЗАМЕЧАНИЯ.

Список системных вызовов Linux можно найти в syscalls(2).

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
В случае ошибки большинство системных вызовов возвращает отрицательное число (т.е., отрицательное значение одной из констант, описанных в errno(3)). Обёртка в библиотеке C скрывает эту информацию от вызывающей стороны: когда системный вызов возвращает отрицательное значение, обёртка копирует абсолютное значение в переменную errno и возвращает -1 в качестве результата своей работы.

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

В некоторых случаях программист должен определить макрос тестирования свойств, чтобы получить объявление системного вызова из заголовочного файла, указанного в справочной странице в разделе СИНТАКСИС. (Где необходимо, эти макросы тестирования свойств должны быть определены перед включением какого-либо заголовочного файла.) В таких случаях требуемый макрос описан в справочной странице. Подробней о макросах тестирования свойств написано в feature_test_macros(7).

## СООТВЕТСТВИЕ СТАНДАРТАМ
Для обозначение вариантов UNIX и разнообразных стандартов, которым соответствуют системные вызовы, описанные в этом разделе, используются различные сокращения. См. standards(7).

## ЗАМЕЧАНИЯ

### Непосредственный вызов
В большинстве случаев, не требуется запускать системный вызов напрямую, но иногда в стандартной библиотеке C может не оказаться нужной обёрточной функции. В этом случае программист должен вручную выполнить системный вызов с помощью syscall(2). Исторически, также осталось возможно сделать с помощью макросов _syscall, описанных в _syscall(2).

### Авторы и условия распространения
Авторы и условия распространения указаны в заголовке исходной справочной страницы. Заметим, что у разных страниц они могут быть разными! Список русских переводчиков для каждой страницы можно найти в .po файле в исходном коде пакета.

## СМОТРИТЕ ТАКЖЕ
_syscall(2), syscall(2), syscalls(2), errno(3), intro(3), capabilities(7), credentials(7), feature_test_macros(7), mq_overview(7), path_resolution(7), pipe(7), pty(7), sem_overview(7), shm_overview(7), signal(7), socket(7), standards(7), symlink(7), sysvipc(7), time(7)


title: io_cancel(2)

summary: отменяет невыполненную асинхронную операцию ввода\-вывода

text:
# io_cancel(2)

## ИМЯ
io_cancel - отменяет невыполненную асинхронную операцию ввода-вывода

## ОБЗОР

```
#include <linux/aio_abi.h>          /* определяет необходимые типы */
```

```
int io_cancel(aio_context_t ctx_id, struct iocb *iocb,
              struct io_event *result);
```

Замечание: В glibc нет обёрточной функции для данного системного вызова; смотрите ЗАМЕЧАНИЯ.

## ОПИСАНИЕ
Системный вызов io_cancel() пытается отменить асинхронную операцию ввода-вывода, ранее отправленную системным вызовом io_submit(2). В В параметре iocb указывается отменяемая операция, а в параметре ctx_id задаётся идентификатор контекста AIO отправленной операции. Если операция успешно отменена, то событие будет скопировано в память, куда указывает result, без помещения в очередь выполнения.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
В случае успешного завершения io_cancel() возвращает 0. В случае ошибки смотрите ЗАМЕЧАНИЯ.

## ОШИБКИ
EAGAIN

Указанный iocb не был отменен.

EFAULT

Одна из структур данных указывает на некорректные данные.

EINVAL

Некорректен контекст AIO, указанный ctx_id.

ENOSYS

Вызов io_cancel() не реализован для этой архитектуры.

## ВЕРСИИ
Асинхронные системные вызовы ввода-вывода впервые появились в Linux 2.5.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Вызов io_cancel() есть только в Linux, и он не должен использоваться в переносимых программах.

## ЗАМЕЧАНИЯ
В glibc нет обёрточной функции для данного системного вызова. Вы можете вызвать его с помощью syscall(2). Но лучше воспользоваться обёрточной функцией io_cancel() из библиотеки libaio.

Заметим, что в обёрточной функции libaio используется другой тип (io_context_t) аргумента ctx_id. Также заметим, что libaio не следует соглашениям обычной библиотеки C для возврата ошибок: при ошибке она возвращает отрицательный номер ошибки (из списка в разделе ОШИБКИ). Если системный вызов вызывается с помощью syscall(2), то возвращаемое значение следует обычным соглашениям для указания на ошибку: возвращается -1 и в errno записывается (положительное) значение возникшей ошибки.

## СМОТРИТЕ ТАКЖЕ
io_destroy(2), io_getevents(2), io_setup(2), io_submit(2), aio(7)


title: io_destroy(2)

summary: уничтожает асинхронный контекст ввода\-вывода

text:
# io_destroy(2)

## ИМЯ
io_destroy - уничтожает асинхронный контекст ввода-вывода

## ОБЗОР

```
#include <linux/aio_abi.h>          /* определяет необходимые типы */
```

```
int io_destroy(aio_context_t ctx_id);
```

Замечание: В glibc нет обёрточной функции для данного системного вызова; смотрите ЗАМЕЧАНИЯ.

## ОПИСАНИЕ
Системный вызов io_destroy() пытается отменить все невыполненные асинхронные операции ввода-вывода, относящиеся к ctx_id, заблокировать выполнение выполнение всех операций, которые нельзя отменить, и уничтожить ctx_id.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
В случае успешного завершения io_destroy() возвращает 0. В случае ошибки смотрите ЗАМЕЧАНИЯ.

## ОШИБКИ
EFAULT

Указанный контекст некорректен.

EINVAL

Некорректен контекст AIO, указанный ctx_id.

ENOSYS

io_destroy() не реализован для этой архитектуры.

## ВЕРСИИ
Асинхронные системные вызовы ввода-вывода впервые появились в Linux 2.5.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Вызов io_destroy() есть только в Linux, и он не должно использоваться в переносимых программах.

## ЗАМЕЧАНИЯ
В glibc нет обёрточной функции для данного системного вызова. Вы можете вызвать его с помощью syscall(2). Но лучше воспользоваться обёрточной функцией io_destroy() из библиотеки libaio.

Заметим, что в обёрточной функции libaio используется другой тип (io_context_t) аргумента ctx_id. Также заметим, что libaio не следует соглашениям обычной библиотеки C для возврата ошибок: при ошибке она возвращает отрицательный номер ошибки (из списка в разделе ОШИБКИ). Если системный вызов вызывается с помощью syscall(2), то возвращаемое значение следует обычным соглашениям для указания на ошибку: возвращается -1 и в errno записывается (положительное) значение возникшей ошибки.

## СМОТРИТЕ ТАКЖЕ
io_cancel(2), io_getevents(2), io_setup(2), io_submit(2), aio(7)


title: io_getevents(2)

text:
# io_getevents(2)

## ИМЯ
io_getevents - считывает асинхронные события ввода/вывода из очереди выполнения

## ОБЗОР

```
#include <linux/aio_abi.h>       /* определяет необходимые типы */
#include <linux/time.h>          /* определяет «struct timespec» */
```

```
int io_getevents(aio_context_t ctx_id, long min_nr, long nr,
                 struct io_event *events, struct timespec *timeout);
```

Замечание: В glibc нет обёрточной функции для данного системного вызова; смотрите ЗАМЕЧАНИЯ.

## ОПИСАНИЕ
Системный вызов io_getevents() пытается считать, по меньшей мере, от min_nr до nr событий из очереди выполнения контекста AIO, указанном в ctx_id.

В аргументе timeout задаётся время (относительное значение) ожидания событий в виде структуры:

```
struct timespec {

    time_t tv_sec;      /* секунды */

    long   tv_nsec;     /* наносекунды [0 .. 999999999] */
};
```

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

Указание в timeout значения NULL приводит к бесконечной блокировке — до получения не менее min_nr событий.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении io_getevents() возвращается количество прочитанных событий. Оно может быть 0 или меньше min_nr, если timeout просрочен. Также может возвращаться ненулевое значение меньше min_nr, если вызов был прерван обработчиком сигнала.

Значения при ошибках смотрите в разделе ЗАМЕЧАНИЯ.

## ОШИБКИ
EFAULT

Задан неправильный указатель в events или timeout.

EINTR

Прерван обработчиком сигнала; смотрите signal(7).

EINVAL

Неверное значение ctx_id. Значение min_nr или nr лежит за пределами диапазона.

ENOSYS

Вызов io_getevents() не реализован для данной архитектуры.

## ВЕРСИИ
Асинхронные системные вызовы ввода-вывода впервые появились в Linux 2.5.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Вызов io_getevents() есть только в Linux, и он не должен использоваться в переносимых программах.

## ЗАМЕЧАНИЯ
В glibc нет обёрточной функции для данного системного вызова. Вы можете вызвать его с помощью syscall(2). Но лучше воспользоваться обёрточной функцией io_getevents() из библиотеки libaio.

Заметим, что в обёрточной функции libaio используется другой тип (io_context_t) аргумента ctx_id. Также заметим, что libaio не следует соглашениям обычной библиотеки C для возврата ошибок: при ошибке она возвращает отрицательный номер ошибки (из списка в разделе ОШИБКИ). Если системный вызов вызывается с помощью syscall(2), то возвращаемое значение следует обычным соглашениям для указания на ошибку: возвращается -1 и в errno записывается (положительное) значение возникшей ошибки.

## ДЕФЕКТЫ
Некорректное значение ctx_id может привести к ошибке сегментирования, а не генерации ошибки EINVAL.

## СМОТРИТЕ ТАКЖЕ
io_cancel(2), io_destroy(2), io_setup(2), io_submit(2), aio(7), time(7)


title: io_setup(2)

summary: создаёт асинхронный контекст ввода\-вывода

text:
# io_setup(2)

## ИМЯ
io_setup - создаёт асинхронный контекст ввода-вывода

## ОБЗОР

```
#include <linux/aio_abi.h>          /* определяет необходимые типы */
```

```
int io_setup(unsigned nr_events, aio_context_t *ctx_idp);
```

Замечание: В glibc нет обёрточной функции для данного системного вызова; смотрите ЗАМЕЧАНИЯ.

## ОПИСАНИЕ
Системный вызов io_setup() создает асинхронный контекст ввода-вывода, способный параллельно обработать nr_events событий. Параметр ctx_idp не должен указывать на уже существующей контекст AIO и должно быть инициализировано 0 перед вызовом. При успешном создании контекста AIO, *ctx_idp заполняется полученным результатом обработки.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
В случае успешного завершения io_setup() возвращает 0. В случае ошибки смотрите ЗАМЕЧАНИЯ.

## ОШИБКИ
EAGAIN

Указанное значение nr_events превышает ограничение пользователя на количество событий, определённое в /proc/sys/fs/aio-max-nr.

EFAULT

В ctx_idp передан некорректный указатель.

EINVAL

Параметр ctx_idp не инициализирован, или указанное в nr_events количество превышает внутренние ограничения. Значение nr_events должно быть больше 0.

ENOMEM

Недостаточно ресурсов ядра.

ENOSYS

io_setup() не реализован для этой архитектуры.

## ВЕРСИИ
Асинхронные системные вызовы ввода-вывода впервые появились в Linux 2.5.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Вызов io_setup() есть только в Linux, и он не должно использоваться в переносимых программах.

## ЗАМЕЧАНИЯ
В glibc нет обёрточной функции для данного системного вызова. Вы можете вызвать его с помощью syscall(2). Но лучше воспользоваться обёрточной функцией io_setup() из библиотеки libaio.

Заметим, что в обёрточной функции libaio используется другой тип (io_context_t *) аргумента ctx_idp. Также заметим, что libaio не следует соглашениям обычной библиотеки C для возврата ошибок: при ошибке она возвращает отрицательный номер ошибки (из списка в разделе ОШИБКИ). Если системный вызов вызывается с помощью syscall(2), то возвращаемое значение следует обычным соглашениям для указания на ошибку: возвращается -1 и в errno записывается (положительное) значение возникшей ошибки.

## СМОТРИТЕ ТАКЖЕ
io_cancel(2), io_destroy(2), io_getevents(2), io_submit(2), aio(7)


title: io_submit(2)

summary: отправляет асинхронные блоки ввода\-вывода для обработки

text:
# io_submit(2)

## ИМЯ
io_submit - отправляет асинхронные блоки ввода-вывода для обработки

## ОБЗОР

```
#include <linux/aio_abi.h>          /* определяет необходимые типы */
```

```
int io_submit(aio_context_t ctx_id, long nr, struct iocb **iocbpp);
```

Замечание: В glibc нет обёрточной функции для данного системного вызова; смотрите ЗАМЕЧАНИЯ.

## ОПИСАНИЕ
Системный вызов io_submit() ставит в очередь nr запросов блоков ввода-вывода для обработки в контексте AIO ctx_id. Значение iocbpp должно быть массивом из nr управляющих блоков AIO, которые будут отправлены в контекст ctx_id.

Структура iocb (блок управления вводом-выводом), определённая в linux/aio_abi.h, описывает параметры, которыми управляется операция ввода-вывода.

```
#include <linux/aio_abi.h>
struct iocb {

    __u64   aio_data;

    __u32   PADDED(aio_key, aio_rw_flags);

    __u16   aio_lio_opcode;

    __s16   aio_reqprio;

    __u32   aio_fildes;

    __u64   aio_buf;

    __u64   aio_nbytes;

    __s64   aio_offset;

    __u64   aio_reserved2;

    __u32   aio_flags;

    __u32   aio_resfd;
};
```

Поля этой структуры имеют следующее назначение:

aio_data

Эти данные копируются в поле data структуры io_event при завершении ввода-вывода (смотрите io_getevents(2)).

aio_key

Внутреннее поле, используется ядром. Не изменяйте это поле после вызова io_submit().

aio_rw_flags

Флаги чтения-записи, передаваемые со структурой. Возможные значения:

RWF_APPEND (начиная с Linux 4.16)

Добавить данный в конец файла. Смотрите описание флага с таким же именем в pwritev2(2), а также описание O_APPEND в open(2). Поле aio_offset игнорируется. Файловое смещение не изменяется.

RWF_DSYNC (начиная с Linux 4.13)

Операция записи завершается согласно требованиям целостности данных синхронизированного ввода-вывода. Смотрите описание флага с тем же именем в pwritev2(2), а также описание O_DSYNC в open(2).

RWF_HIPRI (начиная с Linux 4.13)

Запрос с высоким приоритетом; опросить, если возможно

RWF_NOWAIT (начиная с Linux 4.14)

Не ждать, если ввод-вывод блокирует операции, такие как выделение файловых блоков, очистка грязной страницы, блокировку мьютексов или вызывает перегрузку блочного устройства внутри ядра. Если имеется что-то из этого, то управляющий блок возвращается немедленно со значением -EAGAIN в поле res структуры io_event (смотрите io_getevents(2)).

RWF_SYNC (начиная с Linux 4.13)

Операция записи завершается согласно требованиям целостности файла синхронизированного ввода-вывода. Смотрите описание флага с тем же именем в pwritev2(2), а также описание O_SYNC в open(2).

aio_lio_opcode

Тип ввода-вывода, выполняемый структурой iocb. Возможные значения, определены перечислением в linux/aio_abi.h:

```
enum {

    IOCB_CMD_PREAD = 0,

    IOCB_CMD_PWRITE = 1,

    IOCB_CMD_FSYNC = 2,

    IOCB_CMD_FDSYNC = 3,

    IOCB_CMD_NOOP = 6,

    IOCB_CMD_PREADV = 7,

    IOCB_CMD_PWRITEV = 8,
};

```

aio_reqprio

Определяет приоритет запросов.

aio_fildes

Файловый дескриптор, над которым будут выполняться операции ввода-вывода.

aio_buf

Буфер, используемый для пересылки данных при операции чтения или записи.

aio_nbytes

Размер буфера, на который указывает aio_buf.

aio_offset

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

aio_flags

Набор флагов, связанный со структурой iocb. Допускаемые значения:

IOCB_FLAG_RESFD

Управление асинхронным вводом-выводом должно сигнализировать файловому дескриптору в aio_resfd после выполнения.

IOCB_FLAG_IOPRIO (начиная с Linux 4.18)

Считать поле aio_reqprio как IOPRIO_VALUE, определённое в linux/ioprio.h.

aio_resfd

Файловый дескриптор для сигнализации завершения асинхронного ввода-вывода.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
При успешном выполнении io_submit() возвращает количество отправленных iocb (может быть меньше nr или 0, если nr равно нулю). Случаи ошибок описаны в ЗАМЕЧАНИЯХ.

## ОШИБКИ
EAGAIN

Недостаточно ресурсов для постановки в очередь iocb.

EBADF

Некорректный файловый дескриптор, указанный в первом iocb.

EFAULT

Одна из структур данных указывает на некорректные данные.

EINVAL

Некорректен контекст AIO, указанный ctx_id. Значение nr меньше 0. Значение iocb в *iocbpp[0] некорректно инициализировано, указанная операция некорректна для файлового дескриптора в iocb или некорректное значение в поле aio_reqprio.

ENOSYS

Вызов io_submit() не реализован для этой архитектуры.

EPERM

Поле aio_reqprio содержит класс IOPRIO_CLASS_RT, но представляющий контекст не имеет мандата CAP_SYS_ADMIN.

## ВЕРСИИ
Асинхронные системные вызовы ввода-вывода впервые появились в Linux 2.5.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Вызов io_submit() есть только в Linux, и он не должен использоваться в переносимых программах.

## ЗАМЕЧАНИЯ
В glibc нет обёрточной функции для данного системного вызова. Вы можете вызвать его с помощью syscall(2). Но лучше воспользоваться обёрточной функцией io_submit() из библиотеки libaio.

Заметим, что в обёрточной функции libaio используется другой тип (io_context_t) аргумента ctx_id. Также заметим, что libaio не следует соглашениям обычной библиотеки C для возврата ошибок: при ошибке она возвращает отрицательный номер ошибки (из списка в разделе ОШИБКИ). Если системный вызов вызывается с помощью syscall(2), то возвращаемое значение следует обычным соглашениям для указания на ошибку: возвращается -1 и в errno записывается (положительное) значение возникшей ошибки.

## СМОТРИТЕ ТАКЖЕ
io_cancel(2), io_destroy(2), io_getevents(2), io_setup(2), aio(7)


ioctl

title: ioctl(2)

summary: управляет устройством

text:
# ioctl(2)

## ИМЯ
ioctl - управляет устройством

## ОБЗОР
\#include <sys/ioctl.h>

int ioctl(int fd, unsigned long request, ...);

## ОПИСАНИЕ
Системный вызов ioctl() изменяет параметры нижележащего устройства специальных файлов. В частности, через запросы ioctl() можно управлять многими оперативными характеристиками специальных символьных файлов (например, терминалов). В качестве аргумента fd должен быть указан открытый файловый дескриптор.

Второй аргумент является кодом запроса, значение которого зависит от устройства. Третий аргумент является нетипизированным указателем на память. Обычно, это char *argp (было до тех пор, пока в C не появился vvoid *) и далее он будет называться именно так.

В значении request функции ioctl() кодируется информация является ли параметр входным или выходным и размер аргумента argp в байтах. Макросы и определения, используемые при указании в ioctl() запросах request, определены в файле <sys/ioctl.h>.

## ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
Обычно, при успешном завершении возвращается ноль. В некоторых ioctl() запросах возвращаемое значение считается выходным параметром и при успешном завершении возвращается неотрицательное значение. В случае ошибки возвращается -1 и значение errno устанавливается соответствующим образом.

## ОШИБКИ
EBADF

Значение fd не является правильным файловым дескриптором.

EFAULT

argp ссылается на недоступную область памяти.

EINVAL

Неправильное значение request или argp.

ENOTTY

Значение fd не связано со специальным символьным устройством.

ENOTTY

Указанный запрос не применяется к типу объекта, на который ссылается файловый дескриптор fd.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Нет единого стандарта. Аргументы, возвращаемые значения и семантика ioctl() варьируются в соответствии с драйвером устройства (вызов, используемый как всеохватывающий, не полностью соответствует потоковой модели ввода/вывода в UNIX). В ioctl_list(2) можно найти список многих известных вызовов ioctl(). Системный вызов ioctl() появился в AT&T UNIX версии 7.

## ЗАМЕЧАНИЯ
Чтобы использовать этот вызов требуется открытый файловый дескриптор. Часто вызов open(2) приводит к нежелательным эффектам, которых в Linux можно избежать указав флаг O_NONBLOCK.

## СМОТРИТЕ ТАКЖЕ
execve(2), fcntl(2), ioctl_console(2), ioctl_fat(2), ioctl_ficlonerange(2), ioctl_fideduperange(2), ioctl_getfsmap(2), ioctl_iflags(2), ioctl_list(2), ioctl_ns(2), ioctl_tty(2), ioctl_userfaultfd(2), open(2), sd(4), tty(4)