Создание очереди событий inotify требует определенного количества памяти ядра. По этой причине ядро устанавливает различные ограничения на использование механизма inotify. Суперпользователь может изменять их с помощью трех файлов в каталоге /proc/sys/fs/inotify:
• max_queued_events — при вызове функции inotify_init() это значение используется для установки верхнего ограничения количества событий, которые могут быть поставлены в очередь нового объекта inotify. Если ограничение достигнуто, то происходит генерация события IN_Q_OVERFLOW и удаление лишних событий. Поле wd события переполнения очереди будет иметь значение -1;
• max_user_instances — ограничение количества экземпляров объекта inotify, которые могут быть созданы для одного реального пользовательского идентификатора;
• max_user_watches — ограничение количества элементов списка наблюдения, которые могут быть созданы для одного реального пользовательского идентификатора.
По умолчанию значения, установленные в этих трех файлах, — 16384, 128 и 8192 соответственно.
Linux предоставляет еще один механизм мониторинга событий файлов. Этот механизм под названием dnotify был доступен, начиная с версии ядра 2.4, однако после появления механизма inotify устарел. По сравнению с inotify механизм dnotify страдает целым рядом ограничений.
• Механизм dnotify оповещения о событиях реализован в форме отправки сигналов в приложение. Применение сигналов в качестве механизма оповещения усложняет разработку приложений (раздел 22.12). Кроме того, это затрудняет использование механизма dnotify в рамках библиотеки, так как вызывающая программа может поменять диспозицию сигнала (-ов) оповещения. В механизме inotify сигналы не задействуются. Единицей мониторинга механизма dnotify является каталог. Приложение получает оповещения, когда над любым файлом из данного каталога производится некое действие. В противоположность этому механизм inotify может использоваться для мониторинга каталогов или отдельных файлов.
• Для мониторинга каталога механизму dnotify необходимо, чтобы приложение открыло файловый дескриптор этого каталога. Применение файловых дескрипторов приводит к возникновению двух проблем. Во-первых, из-за того, что файловая система, содержащая данный каталог, занята, она не может быть размонтирована. Во-вторых, так как для каждого каталога требуется отдельный файловый дескриптор, приложение может в конце концов потребить большое количество дескрипторов. Так как механизм inotify не использует файловые дескрипторы, описанных проблем удается избежать.
• Информация о событиях, предоставляемая механизмом dnotify, менее точна по сравнению с информацией, предоставляемой inotify. Так, при изменении файла в наблюдаемом каталоге dnotify сообщает нам, что произошло событие, однако не сообщает, какой файл стал частью данного события. Приложение может определить это перехватом информации о содержимом каталога. Более того, механизм inotify предоставляет более детализированную информацию о произошедшем событии по сравнению с dnotify.
• В некоторых случаях механизм dnotify не предоставляет надежную информацию о событиях файлов.
Дополнительную информацию о механизме dnotify можно найти на странице fcntl(2) руководства в разделе с описанием F_NOTIFY, а также в ресурсах с информацией о ядре Documentation/dnotify.txt.
Специфичный механизм Linux inotify позволяет приложению получать уведомления, когда с набором наблюдаемых файлов и каталогов происходят различные события (файлы открываются, закрываются, создаются, удаляются, изменяются, переименовываются и т. д.). Механизм inotify вытеснил старый механизм dnotify.
19.1. Напишите программу, которая протоколировала бы все создания, удаления и переименования внутри каталога, указанного в аргументе командной строки программы. Она должна осуществлять мониторинг событий во всех подкаталогах внутри указанного каталога. Для получения списка всех подкаталогов вам потребуется воспользоваться функцией nftw() (см. раздел 18.9). При добавлении нового подкаталога в дерево или при удалении каталога набор наблюдаемых подкаталогов должен быть обновлен соответствующим образом.
В этой и двух следующих главах мы обсуждаем сигналы. Несмотря на то что сами фундаментальные концепции достаточно просты, наше обсуждение будет довольно длинным из-за большого количества деталей, которые следует охватить.
В этой главе мы рассмотрим:
• различные сигналы и их предназначение;
• обстоятельства, при которых ядро может сгенерировать сигнал процессу, а также системные вызовы, которые один процесс может использовать для отправки сигнала другому;
