Scroll to navigation

inotify(7) Miscellaneous Information Manual inotify(7)

ИМЯ

inotify - наблюдает за событиями файловой системы

ОПИСАНИЕ

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

В программный интерфейс входят следующие системные вызовы:

Вызов inotify_init(2) создаёт экземпляр inotify и возвращает файловый дескриптор, ссылающийся на экземпляр inotify. Более новый inotify_init1(2) подобен inotify_init(2), но имеет аргумент flags, который предоставляет доступ к некоторым дополнительным возможностям.
Вызов inotify_add_watch(2) изменяет «список наблюдения», связанный с экземпляром inotify. Каждый элемент (сторожок (watch)) в списке задаёт путь к файлу или каталогу и некоторый набор событий, которые ядро должно отслеживать для файла, на который указывает этот путь. Вызов inotify_add_watch(2) или создаёт новый сторожок, или изменяет существующий. Каждый сторожок имеет уникальный «дескриптор сторожка» — целое число, возвращаемое inotify_add_watch(2) при создании сторожка.
При возникновении событий с отслеживаемыми файлами и каталогами, эти события становятся доступны приложению в виде структурированных данных, которые можно прочитать из файлового дескриптора inotify с помощью read(2) (смотрите ниже).
Вызов inotify_rm_watch(2) удаляет элемент из списка наблюдения inotify.
При закрытии (с помощью close(2)) файловых дескрипторов, ссылающихся на экземпляр inotify, этот объект и его ресурсы освобождаются для повторного использования ядром; все связанные сторожки освобождаются автоматически.

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

Чтение событий из файлового дескриптора inotify

Чтобы определить, что события произошли, приложение должно прочитать (read(2)) файловый дескриптор inotify. Если событий не было, то предполагая, что это блокирующий файловый дескриптор, вызов read(2) заблокирует работу до возникновения, по крайней мере, одного события (если не будет прерван сигналом; в этом случае вызов завершается с ошибкой EINTR, смотрите signal(7)).

При успешном выполнении read(2) возвращает буфер с одной или более структурами следующего вида:


struct inotify_event {

int wd; /* дескриптор наблюдаемого */
uint32_t mask; /* маска, описывающая событие */
uint32_t cookie; /* уникальный cookie, связывающий относящиеся
друг к другу события (для rename(2)) */
uint32_t len; /* размер поля name */
char name[]; /* необязательное имя, завершающееся null */ };

В wd указывается сторожок, к которому относится событие. Это один из дескрипторов сторожка, полученный из вызова inotify_add_watch(2).

В mask содержатся биты, описывающие возникшее событие (смотрите ниже).

Значение cookie — это уникальное целое, которое объединяет связанные события. В настоящее время используется только для событий переименования и позволяет приложению объединить возвращаемые IN_MOVED_FROM и IN_MOVED_TO в пару событий. Для остальных типов событий значение cookie равно 0.

The name field is present only when an event is returned for a file inside a watched directory; it identifies the filename within the watched directory. This filename is null-terminated, and may include further null bytes ('\0') to align subsequent reads to a suitable address boundary.

Поле len содержит количество всех байт в name, включая байты null; длина каждой структуры inotify_event равна sizeof(struct inotify_event)+len.

The behavior when the buffer given to read(2) is too small to return information about the next event depends on the kernel version: before Linux 2.6.21, read(2) returns 0; since Linux 2.6.21, read(2) fails with the error EINVAL. Specifying a buffer of size


sizeof(struct inotify_event) + NAME_MAX + 1

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

События inotify

В аргументе inotify_add_watch(2) mask и поле mask структуры inotify_event, возвращаемых при чтении файлового дескриптора inotify, содержатся битовые маски, определяющие события inotify. Следующие биты могут быть заданы в mask при вызове inotify_add_watch(2) и возвращены в поле mask, возвращаемом read(2):

Был произведён доступ к файлу (например, read(2), execve(2)).
Metadata changed—for example, permissions (e.g., chmod(2)), timestamps (e.g., utimensat(2)), extended attributes (setxattr(2)), link count (since Linux 2.6.25; e.g., for the target of link(2) and for unlink(2)), and user/group ID (e.g., chown(2)).
Файл, открытый для записи, был закрыт.
Файл или каталог, не открытый для записи, был закрыт.
В отслеживаемом каталоге был создан файл/каталог (например, open(2) O_CREAT, mkdir(2), link(2), symlink(2), bind(2) для доменного сокета UNIX).
В отслеживаемом каталоге был удалён файл/каталог.
Отслеживаемый файл/каталог был удалён (это событие также возникает, если объект перемещён в другую файловую систему, так как mv(1), фактически, копирует файл в другую файловую систему и удаляет его из исходной). Также затем будет создано событие IN_IGNORED для дескриптора сторожка.
Файл был изменён (например, write(2), truncate(2)).
Отслеживаемый файл/каталог был перемещён.
При переименовании генерируется для каталога, содержащего старое имя файла.
При переименовании генерируется для каталога, содержащего новое имя файла.
Файл или каталог был открыт.

Наблюдение inotify ведётся за inode: при наблюдении за файлом (но не когда наблюдение ведётся за каталогом, содержащим файл) событие может генерироваться при активности по любой ссылке на файл (находящейся в том же или в другом каталоге).

При наблюдении за каталогом:

события, помеченные звёздочкой (*), могут возникать как для самого каталога, так и для файлов в каталоге; и
события, помеченные знаком плюс (+), могут возникать только для объектов внутри каталога (но не самого каталога).

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

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

Макрос IN_ALL_EVENTS определён как битовая маска всех перечисленных выше событий. Данный макрос можно использовать в качестве аргумента mask в вызове inotify_add_watch(2).

Дополнительно, два удобных макроса:

То же, что и IN_MOVED_FROM | IN_MOVED_TO.
То же, что и IN_CLOSE_WRITE | IN_CLOSE_NOWRITE.

Также, при вызове inotify_add_watch(2) в mask могут быть указаны следующие биты:

Не разыменовывать pathname, если это символическая ссылка.
По умолчанию, при слежении за событиями для потомков каталога, события генерируются для потомков даже после того, как они будут удалены из каталога. Это может привести к большому количеству ненужных для приложения событий (например, если следить за /tmp, в котором многие приложения создают и сразу удаляют временные файлы). Указание IN_EXCL_UNLINK изменяет поведение по умолчанию, и такие события не генерируются для потомков после удаления из отслеживаемого каталога.
Если экземпляр слежения уже существует для объекта файловой системы соответствующего pathname, то выполнять добавление (OR) событий в mask к маске слежения (вместо замены маски); если также указан IN_MASK_CREATE, то возвращается ошибка EINVAL.
Отслеживать объект файловой системы, соответствующий pathname до одного события, затем удалить объект из списка слежения.
Следить за pathname, только если это каталог; если pathname не является каталогом, то возвращается ошибка ENOTDIR. Этот флаг предоставляет приложению бессостязательный способ убедиться, что отслеживаемый объект — каталог.
Следить за pathname только, если за ним никто не следит; если уже выполняется слежение за pathname, то возвращается ошибка EEXIST.
С помощью этого флага приложение может быть уверено, что новые слежения не изменят существующих. Это полезно, так как несколько путей могут ссылаться на одну иноду, а несколько вызовов inotify_add_watch(2) без этого флага могут затереть существующие маски слежения.

Следующие биты могут быть установлены в поле mask при возврате из read(2):

Слежение было снято явно (inotify_rm_watch(2)) или автоматически (файл был удалён или размонтирована файловая система). Также смотрите ДЕФЕКТЫ.
Объект этого события — каталог.
Переполнена очередь событий (для этого события значение wd равно -1).
Файловая система, содержащая отслеживаемый объект, была размонтирована. Также, будет сгенерировано событие IN_IGNORED для дескриптора сторожка.

Примеры

Предположим, приложение следит за всеми событиями для каталога dir и файла dir/myfile. В примере ниже показаны некоторые события, которые будут сгенерированы для этих двух объектов.

Генерируется событие IN_OPEN и для dir, и для dir/myfile.
Генерируется событие IN_ACCESS и для dir, и для dir/myfile.
Генерируется событие IN_MODIFY и для dir, и для dir/myfile.
Генерируется событие IN_ATTRIB и для dir, и для dir/myfile.
Генерируется событие IN_CLOSE_WRITE и для dir, и для dir/myfile.

Предположим, приложение следит за всеми событиями для каталогов dir1 и dir2 и файла dir1/myfile. В примере ниже показаны некоторые события, которые могут быть сгенерированы.

Генерируется событие IN_ATTRIB для myfile и событие IN_CREATE для dir2.
Генерируется событие IN_MOVED_FROM для dir1, событие IN_MOVED_TO для dir2 и событие IN_MOVE_SELF для myfile. События IN_MOVED_FROM и IN_MOVED_TO будут содержать одинаковое значение cookie.

Предположим, что dir1/xx и dir2/yy только ссылки на один файл и приложение следит за dir1, dir2, dir1/xx и dir2/yy. При выполнение следующих вызовов в порядке, указанном ниже, будут сгенерированы следующие события:

Генерируется событие IN_ATTRIB для xx (так как изменился его счётчик ссылок) и событие IN_DELETE для dir2.
Генерируется событие IN_ATTRIB, IN_DELETE_SELF и IN_IGNORED для xx и событие IN_DELETE для dir1.

Предположим, приложение следит за каталогом dir и пустым каталогом dir/subdir. В примере ниже показаны некоторые события, которые могут быть сгенерированы.

Генерируется событие IN_CREATE | IN_ISDIR для dir.
Генерируются события IN_DELETE_SELF и IN_IGNORED для subdir и событие IN_DELETE | IN_ISDIR для dir.

Интерфейс /proc

Для ограничения потребления inotify памяти ядра, можно использовать следующие интерфейсы:

/proc/sys/fs/inotify/max_queued_events
Значение в этом файле используется когда приложение вызывает inotify_init(2) для установки верхнего порога количества событий, которые могут поместиться в очередь соответствующего экземпляра inotify. События, превысившие это ограничение, отбрасываются, но событие IN_Q_OVERFLOW генерируется всегда.
/proc/sys/fs/inotify/max_user_instances
В этом файле задаётся ограничение на количество экземпляров inotify, которые могут быть созданы для одного реального идентификатора пользователя.
/proc/sys/fs/inotify/max_user_watches
В этом файле задаётся ограничение на количество сторожков, которые могут быть созданы для одного реального идентификатора пользователя.

СТАНДАРТЫ

Linux.

ИСТОРИЯ

Inotify was merged into Linux 2.6.13. The required library interfaces were added in glibc 2.4. (IN_DONT_FOLLOW, IN_MASK_ADD, and IN_ONLYDIR were added in glibc 2.5.)

ЗАМЕЧАНИЯ

За файловыми дескрипторами inotify можно наблюдать с помощью select(2), poll(2), и epoll(7). Когда возникает событие, файловый дескриптор указывает на возможность чтения.

Начиная с Linux 2.6.25, для файловых дескрипторов inotify стали доступны уведомления ввода-вывода посредством сигналов; смотрите обсуждение F_SETFL (для установки флага O_ASYNC), F_SETOWN и F_SETSIG в fcntl(2). Структура siginfo_t (описана в sigaction(2)), передаваемая обработчику сигнала, содержит следующие настройки полей: в si_fd указывается номер файлового дескриптора inotify; в si_signo указывается номер сигнала; в si_code указывается POLL_IN; в si_band указывается POLLIN.

Если последующие события inotify, выводимые в файловый дескриптор inotify, одинаковы (содержат одинаковые значения wd, mask, cookie и name), то они сливаются в одно событие, если самое старое событие ещё не прочитано (но смотрите ДЕФЕКТЫ). Это сокращает требуемое количество памяти ядра для очереди событий, но также означает, что приложение не может использовать inotify для надёжного подсчёта файловых событий.

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

The set of watch descriptors that is being monitored via an inotify file descriptor can be viewed via the entry for the inotify file descriptor in the process's /proc/pid/fdinfo directory. See proc(5) for further details. The FIONREAD ioctl(2) returns the number of bytes available to read from an inotify file descriptor.

Ограничения и подводные камни

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

Inotify сообщает только о событиях, которые возникли из-за пользовательских программ, использовавших программный интерфейс файловой системы. То есть, не возникает событий для файловых систем, доступных по сети (приложения должны использовать старый метод опроса файловой системы для слежения за такими событиями). Кроме того, различные псевдо-файловый системы, такие как /proc, /sys и /dev/pts, не отслеживаются через inotify.

Программный интерфейс inotify не сообщает о доступе и изменениях, которые могут произойти из-за mmap(2), msync(2) и munmap(2).

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

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

Отслеживание каталогов через inotify ведётся не рекурсивно: чтобы отслеживать подкаталоги, нужно создать дополнительные сторожки. Это может занять много времени при большом дереве каталога.

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

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

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

Работа с событиями rename()

Как указывалось выше, из событий IN_MOVED_FROM и IN_MOVED_TO, генерируемых rename(2), можно определить пару по их одинаковому значению cookie. Однако, с этой задачей есть несколько проблем.

Эти два события, обычно, стоят друг за другом в потоке событий, если читать из файлового дескриптора inotify. Однако, это не гарантируется. Если несколько процессов создают события для отслеживаемых объектов, то (в редких случаях) произвольное количество других событий может появиться между событиями IN_MOVED_FROM и IN_MOVED_TO. Кроме того, не гарантируется, что пара событий вставляется в очередь атомарно: может существовать короткий интервал, в котором IN_MOVED_FROM уже появилось, а IN_MOVED_TO ещё нет.

Соответствие IN_MOVED_FROM и IN_MOVED_TO паре событий, сгенерированных rename(2), по сути, просто (не забудьте, что если объект переименовывается вне отслеживаемого каталога, то может не быть даже события IN_MOVED_TO). Можно использовать эвристические предположения (например, что события всегда следуют друг за другом), что работает в большинстве случаев, но неминуемо не сработает в некоторых случаях, в которых приложение посчитает события IN_MOVED_FROM и IN_MOVED_TO несвязными. Если в результате дескрипторы сторожков будут уничтожены и пересозданы, то такие дескрипторы будут несогласованны с дескрипторами сторожков для любых ожидающих событий (пересоздание файлового дескриптора inotify и пересборка кэша может быть полезна в этом случае).

Applications should also allow for the possibility that the IN_MOVED_FROM event was the last event that could fit in the buffer returned by the current call to read(2), and the accompanying IN_MOVED_TO event might be fetched only on the next read(2), which should be done with a (small) timeout to allow for the fact that insertion of the IN_MOVED_FROM+IN_MOVED_TO event pair is not atomic, and also the possibility that there may not be any IN_MOVED_TO event.

ДЕФЕКТЫ

До Linux 3.19, fallocate(2) не создавал события inotify. Начиная с Linux 3.19, вызов fallocate(2) генерирует событие IN_MODIFY.

Before Linux 2.6.16, the IN_ONESHOT mask flag does not work.

В первоначальной задумке и реализации флаг IN_ONESHOT не приводил к генерации события IN_IGNORED, если наблюдение отменялось после одного события. Однако, как непреднамеренный эффект других изменений, начиная с Linux 2.6.36, событие IN_IGNORED в этом случае генерируется.

Before Linux 2.6.25, the kernel code that was intended to coalesce successive identical events (i.e., the two most recent events could potentially be coalesced if the older had not yet been read) instead checked if the most recent event could be coalesced with the oldest unread event.

When a watch descriptor is removed by calling inotify_rm_watch(2) (or because a watch file is deleted or the filesystem that contains it is unmounted), any pending unread events for that watch descriptor remain available to read. As watch descriptors are subsequently allocated with inotify_add_watch(2), the kernel cycles through the range of possible watch descriptors (1 to INT_MAX) incrementally. When allocating a free watch descriptor, no check is made to see whether that watch descriptor number has any pending unread events in the inotify queue. Thus, it can happen that a watch descriptor is reallocated even when pending unread events exist for a previous incarnation of that watch descriptor number, with the result that the application might then read those events and interpret them as belonging to the file associated with the newly recycled watch descriptor. In practice, the likelihood of hitting this bug may be extremely low, since it requires that an application cycle through INT_MAX watch descriptors, release a watch descriptor while leaving unread events for that watch descriptor in the queue, and then recycle that watch descriptor. For this reason, and because there have been no reports of the bug occurring in real-world applications, as of Linux 3.15, no kernel changes have yet been made to eliminate this possible bug.

ПРИМЕРЫ

The following program demonstrates the usage of the inotify API. It marks the directories passed as a command-line arguments and waits for events of type IN_OPEN, IN_CLOSE_NOWRITE, and IN_CLOSE_WRITE.

Следующий вывод был записан при редактировании файла /home/user/temp/foo и просмотра каталога /tmp. Перед открытием файла и каталога произошли события IN_OPEN. После закрытия файла произошло событие IN_CLOSE_WRITE. После закрытия каталога произошло событие IN_CLOSE_NOWRITE. Выполнение программы закончилось после нажатия пользователем клавиши ENTER.

Пример вывода


$ ./a.out /tmp /home/user/temp
Press enter key to terminate.
Listening for events.
IN_OPEN: /home/user/temp/foo [file]
IN_CLOSE_WRITE: /home/user/temp/foo [file]
IN_OPEN: /tmp/ [directory]
IN_CLOSE_NOWRITE: /tmp/ [directory]
Listening for events stopped.

Исходный код программы

#include <errno.h>
#include <poll.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/inotify.h>
#include <unistd.h>
#include <string.h>
/* Read all available inotify events from the file descriptor 'fd'.

wd is the table of watch descriptors for the directories in argv.
argc is the length of wd and argv.
argv is the list of watched directories.
Entry 0 of wd and argv is unused. */ static void handle_events(int fd, int *wd, int argc, char* argv[]) {
/* Some systems cannot read integer variables if they are not
properly aligned. On other systems, incorrect alignment may
decrease performance. Hence, the buffer used for reading from
the inotify file descriptor should have the same alignment as
struct inotify_event. */
char buf[4096]
__attribute__ ((aligned(__alignof__(struct inotify_event))));
const struct inotify_event *event;
ssize_t len;
/* Loop while events can be read from inotify file descriptor. */
for (;;) {
/* Read some events. */
len = read(fd, buf, sizeof(buf));
if (len == -1 && errno != EAGAIN) {
perror("read");
exit(EXIT_FAILURE);
}
/* If the nonblocking read() found no events to read, then
it returns -1 with errno set to EAGAIN. In that case,
we exit the loop. */
if (len <= 0)
break;
/* Loop over all events in the buffer. */
for (char *ptr = buf; ptr < buf + len;
ptr += sizeof(struct inotify_event) + event->len) {
event = (const struct inotify_event *) ptr;
/* Print event type. */
if (event->mask & IN_OPEN)
printf("IN_OPEN: ");
if (event->mask & IN_CLOSE_NOWRITE)
printf("IN_CLOSE_NOWRITE: ");
if (event->mask & IN_CLOSE_WRITE)
printf("IN_CLOSE_WRITE: ");
/* Print the name of the watched directory. */
for (size_t i = 1; i < argc; ++i) {
if (wd[i] == event->wd) {
printf("%s/", argv[i]);
break;
}
}
/* Print the name of the file. */
if (event->len)
printf("%s", event->name);
/* Print type of filesystem object. */
if (event->mask & IN_ISDIR)
printf(" [directory]\n");
else
printf(" [file]\n");
}
} } int main(int argc, char* argv[]) {
char buf;
int fd, i, poll_num;
int *wd;
nfds_t nfds;
struct pollfd fds[2];
if (argc < 2) {
printf("Usage: %s PATH [PATH ...]\n", argv[0]);
exit(EXIT_FAILURE);
}
printf("Press ENTER key to terminate.\n");
/* Create the file descriptor for accessing the inotify API. */
fd = inotify_init1(IN_NONBLOCK);
if (fd == -1) {
perror("inotify_init1");
exit(EXIT_FAILURE);
}
/* Allocate memory for watch descriptors. */
wd = calloc(argc, sizeof(int));
if (wd == NULL) {
perror("calloc");
exit(EXIT_FAILURE);
}
/* Mark directories for events
- file was opened
- file was closed */
for (i = 1; i < argc; i++) {
wd[i] = inotify_add_watch(fd, argv[i],
IN_OPEN | IN_CLOSE);
if (wd[i] == -1) {
fprintf(stderr, "Cannot watch '%s': %s\n",
argv[i], strerror(errno));
exit(EXIT_FAILURE);
}
}
/* Prepare for polling. */
nfds = 2;
fds[0].fd = STDIN_FILENO; /* Console input */
fds[0].events = POLLIN;
fds[1].fd = fd; /* Inotify input */
fds[1].events = POLLIN;
/* Wait for events and/or terminal input. */
printf("Listening for events.\n");
while (1) {
poll_num = poll(fds, nfds, -1);
if (poll_num == -1) {
if (errno == EINTR)
continue;
perror("poll");
exit(EXIT_FAILURE);
}
if (poll_num > 0) {
if (fds[0].revents & POLLIN) {
/* Console input is available. Empty stdin and quit. */
while (read(STDIN_FILENO, &buf, 1) > 0 && buf != '\n')
continue;
break;
}
if (fds[1].revents & POLLIN) {
/* Inotify events are available. */
handle_events(fd, wd, argc, argv);
}
}
}
printf("Listening for events stopped.\n");
/* Close inotify file descriptor. */
close(fd);
free(wd);
exit(EXIT_SUCCESS); }

СМ. ТАКЖЕ

inotifywait(1), inotifywatch(1), inotify_add_watch(2), inotify_init(2), inotify_init1(2), inotify_rm_watch(2), read(2), stat(2), fanotify(7)

Файл Documentation/filesystems/inotify.txt в дереве исходного кода ядра Linux

ПЕРЕВОД

Русский перевод этой страницы руководства был сделан Azamat Hackimov <azamat.hackimov@gmail.com>, Dmitriy S. Seregin <dseregin@59.ru>, Yuri Kozlov <yuray@komyakino.ru> и Иван Павлов <pavia00@gmail.com>

Этот перевод является бесплатной документацией; прочитайте Стандартную общественную лицензию GNU версии 3 или более позднюю, чтобы узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ.

Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте электронное письмо на man-pages-ru-talks@lists.sourceforge.net.

8 июля 2023 г. Linux man-pages 6.05.01