inotify

ИМЯ

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

•

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

•

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

Замечание: при слежении за каталогом события не генерируются для файлов каталога, если событие возникает по пути (т. е., по ссылке), который находится вне отслеживаемого каталога. Когда события генерируются для объектов внутри отслеживаемого каталога, поле name, возвращаемое в структуре inotify_event, хранит имя файла внутри этого каталога. Макрос IN_ALL_EVENTS определён как битовая маска всех перечисленных выше событий. Данный макрос можно использовать в качестве аргумента mask в вызове inotify_add_watch(2). Дополнительно, два удобных макроса: Также, при вызове inotify_add_watch(2) в mask могут быть указаны следующие биты: Следующие биты могут быть установлены в поле mask при возврате из read(2):

Примеры

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

Интерфейс /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

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

ВЕРСИИ

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 есть только в Linux.

ЗАМЕЧАНИЯ

За файловыми дескрипторами 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. Когда дескриптор сторожка удаляется вызовом inotify_rm_watch(2) (или из-за удаления отслеживаемого файла, или размонтирования содержащей его файловой системы), все ожидающие непрочитанные события для этого дескриптора сторожка остаются доступными для чтения. Так как дескрипторы сторожков в дальнейшем циклически выделяются inotify_add_watch(2), ядро поступательно проходит через диапазон возможных дескрипторов сторожков (от 0 до INT_MAX). При выделении свободного дескриптора сторожка для выбранного номера не производится проверка того, есть ли какие-то ожидающие непрочитанные события в очереди inotify с таким номером или нет. То есть может случиться так, что дескриптор сторожка выделяется повторно даже когда существуют ожидающие непрочитанные события, оставшиеся от предыдущего выделения дескриптора сторожка с тем же номером; в результате приложение может прочесть эти события и посчитать их как принадлежащие файлу, связанному с новым повторно задействованным дескриптором сторожка. На практике, вероятность столкновения с этой ошибкой может быть чрезвычайно низка, так как для этого требуется, чтобы приложения циклически перебрало все INT_MAX дескрипторов сторожков, освободило дескриптор сторожка и оставило непрочитанные события этого дескриптора сторожка в очереди, а затем повторно задействовало этот дескриптор сторожка. По этой причине и из-за того, что ещё никто не сообщал об этой ошибке в реальности, на момент актуальности Linux 3.15, в ядре ничего не было сделано для того, чтобы устранить этот дефект.

ПРИМЕРЫ

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
Нажмите ENTER для завершения работы.
Ожидание событий.
IN_OPEN: /home/user/temp/foo [файл]
IN_CLOSE_WRITE: /home/user/temp/foo [файл]
IN_OPEN: /tmp/ [каталог]
IN_CLOSE_NOWRITE: /tmp/ [каталог]

Ожидание событий прекращено.

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

#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[])
{
    /* В некоторых системах невозможно прочитать целые переменные, если
       они неправильно выровнены. В других системах некорректное
       выравнивание может снижать производительность. Таким образом, буфер,
       используемый для чтения из файлового дескриптора inotify, должен быть
       выровнен также как структура struct inotify_event. */

    char buf[4096]
        __attribute__ ((aligned(__alignof__(struct inotify_event))));
    const struct inotify_event *event;
    ssize_t len;

    /* проходим по всем событиям, которые можем прочитать
       из файлового дескриптора inotify */

    for (;;) {

        /* читаем несколько событий */

        len = read(fd, buf, sizeof(buf));
        if (len == -1 && errno != EAGAIN) {
            perror("read");
            exit(EXIT_FAILURE);
        }

        /* Если неблокирующий read() не найдёт событий для чтения, то
           вернёт -1 с errno равным EAGAIN. В этом случае
           выходим из цикла. */

        if (len <= 0)
            break;

        /* Проходим по всем событиям в буфере. */

        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(" [каталог]\n");
            else
                printf(" [файл]\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("Использование: %s ПУТЬ [ПУТЬ …]\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    printf("Нажмите ENTER для завершения работы.\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);
    }

    /* помечаем каталоги для событий
       - файл был открыт
       - файл был закрыт */

    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);
        }
    }

    /* Подготовка к опросу. */

    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("Ожидание событий.\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("Ожидание событий прекращено.\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 <[email protected]>, Dmitriy S. Seregin <[email protected]>, Yuri Kozlov <[email protected]> и Иван Павлов <[email protected]> Этот перевод является бесплатной документацией; прочитайте Стандартную общественную лицензию GNU версии 3 или более позднюю, чтобы узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ. Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте электронное письмо на [email protected]