Мониторинг изменения файлов linux

Inotify-tools: осуществляем мониторинг изменении файловой системы в Linux

Linux — гибкая операционная система, которая вооружает пользователя широкими возможностями. Вот, например, нам необходимо осуществить мониторинг изменения файловой системы. Для этого в Linux появился отличный инструментарий, да ещё, ориентированный на консоль. О нем и пойдет речь далее.

Inotify — подсистема ядра

Inotify — это подсистема ядра Linux, которая отслеживает изменения файловой системы в Linux (открытие, чтение, создание, удаление, перемещение, изменение атрибутов и др.). Впервые данная подсистема появилась в релизе ядра 2.6.13. Другими словами, подсистема позволяет получить информацию о действиях, которые были осуществлены с любым интересующим вас файлом.

Inotify-tools: знакомство и установка

Inotify-tools — это набор утилит, которые посредством командной строки позволяют работать с подсистемой Inotify. Кроме того, составной часть проекта Inotify-tools является соответствующая библиотека — libinotifytools , которая позволяет с легкостью задействовать интерфейс, предоставляемый подсистемой Inotify.

Мы будем использовать операционную систему Ubuntu 11.10. Установка Inotify-tools в ней не займёт много времени. Что касается других дистрибутивов (последних версий), то рассматриваемый пакет утилит доступен из репозиториев для openSUSE 12.1, Debian 6.x, Arch и других.

Запустите терминал или перейдите в консоль, а затем дайте команду:

Кстати, если вы обратите внимание, то увидите, что, помимо inotify-tools будет установлен пакет — libinotifytools0. Это та самая библиотека, о которой мы говорили выше, и которая необходима для работы inotify-tools.

Работаем с Inotify-tools

В пакет inotify-tools входят следующие утилиты: inotifywatch и inotifywait . inotifywatch — эта утилита, которая дает представление о том, какую информацию можно получить с помощью подсистемы Inotify, а также осуществляет сбор статистической информации о соответствующих событиях файловой системы (открытие файлов, удаление и т. д. — далее, в этом контексте будут иметься ввиду события Inotify).

Рассмотрим на примерах, как это работает. Откройте терминал и дайте команду:

После чего вы увидите на экране примерно следующее (см. рис. 1)

Рисунок 1. inotifywatch в процессе работы

Это означает, что inotifywatch успешно запущен и осуществляет рекурсивный (опция «-r») сбор информации о действиях с файловой системой в домашнем каталоге текущего пользователя. Например, запустим браузер Mozilla Firefox и закроем его. Далее нажмём в терминале «Ctrl»+»C», чтобы остановить inotifywatch . В итоге мы увидим примерно следующее (см. рис. 2, для увеличения щелкните по рисунку мышкой).

Рисунок. 2. Вывод Inotifywatch

В этом выводе вы можете увидеть к каким файлам обращался Mozilla Firefox во время своей работы.

При помощи опции «-e» можно добиться более гибкого вывода информации от inotifywatch . Так, например, нам необходимо узнать какие файлы или каталоги во время своей работы открывает Mozilla Firefox. Дадим следующую команду:

После этого, запустим Mozilla Firefox, поработаем в нем, а затем закроем. Далее остановим в терминале, как в прошлый раз («Ctrl»+»C»), и работу самой утилиты inotifywatch . В выводе мы уже увидим все лишь три «колонки» — total, open и filename (см. рис. 3).

Рисунок 3. Вывод inotifywatch при использовании опции «-e»

Воспользовавшись справкой для данной утилиты, вы можете увидеть, что inotifywatch способна собирать информацию о довольно большом количестве событий. Получить справку по inotifywatch можно с помощью соответствующего руководства man ( man inotifywatch ), а также указав перед данной командой опцию — «-h».

Итак, inotifywatch не отображает статистику о событиях файловой системы сразу. Но, что делать когда необходимо получать информацию о событиях сразу, как они начинают происходить. Во общем, осуществлять мониторинг. В этом нам поможет вторая утилита из пакета Inotify-tools — inotifywait .

Дайте следующую команду:

где опция «-m» — указывает осуществлять мониторинг событий, без этой опции inotifywait прекратит работу после первого события; опция «-r» — указывает осуществлять рекурсивный сбор информации о действиях с файловой системой.

А запустив Mozilla Firefox, вы увидите все файлы, к которым обращается браузер, а также, действия, которые он с ними осуществляет (создание временных файлов, обращение к внутренним базам данных sqlite и т.д.).

Для получения справки по работе с inotifywait воспользуйтесь соответствующей страницей руководств, а также используйте опцию «-h».

Заключение

inotify-tools удобный инструмент мониторинга событий файловой системы. Кроме того, в ситуация, когда необходимо получить сведения о файлах и каталогах, к которым обращается та или иная программа, inotify-tools может стать лучшим решением, т. к. имеет небольшой объем и мало зависимостей, а также является интерфейсом для подсистемы ядра — Inotify.

Источники и дополнительные материалы:

2. Проект Inotify-tools на GitHub — https://github.com/rvoicilas/inotify-tools/;

3. Исходный код libinotifytools — https://github.com/rvoicilas/inotify-tools/tree/master/libinotifytools/src;

4. Сайт посвященный libinotifytools — http://inotify-tools.sourceforge.net/api/index.html;

5. К. Вервлоесем. Inotify: Следим за системой // Linux Format. — N 1. — 2011. — с. 80 — 83.

Источник

Мониторинг за изменениями файловой системы

В поисках готового велосипеда для решения задачи мониторинга за изменениями в ФС с поддержкой linux+freebsd наткнулся на приятную python либу watchdog (github, packages.python.org). Которая помимо интересных мне ОС поддерживает также MacOS (есть своя специфика) и Windows.
Тем, кому данный вопрос интересен и кого не отпугнет индийское происхождение автора, прошу .

Установка

Можно взять готовую версию из PIP:
$ pip install watchdog
Сам PIP ставится как пакет python-pip, порт devel/py-pip, etc.
Либо собрать из исходников через setup.py.

Достаточно подробно все расписано в оригинальном руководстве. Правда там описание версии 0.5.4, а сейчас актуальна 0.6.0. Однако, вся разница в правке копирайтов и замене отступа в 4 пробела на отступ в 2. «Google code style» 🙂

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

Кроме того, собрать модуль можно на несовместимой ОС, но тогда в дело вступится fallback-реализация, делающая «слепки» структуры ФС с последующими сравнениями. Возможно, так кто-то и делал у себя при решении подобной задачи 🙂

Сам же я пробовал собрать под ubuntu 11.4 и freebsd-8.2 RELEASE, каких-либо проблем при сборке и работе не возникло.

Базовый пример

Предположим, что нас интересуют изменения по некоему пути /path/to/smth, связанные с созданием, удалением и переименованием файлов и директорий.

Класс Observer выбирается в /observers/__init__.py исходя из возможностей вашей ОС, так что нет необходимости самостоятельно решать, что же выбрать.
Класс FileSystemEventHandler является базовым классом обработчика событий изменения. Он мало что умеет, но мы научим его потомка:

Полный список методов можно увидеть в самом FileSystemEventHandler.dispatch: on_modified, on_moved, on_created, on_deleted.

Запускаем это все:

Observer является относительно далеким потомком threading.Thread, соотвественно после вызова start() мы получаем фоновый поток, следящий за изменениями. Так что если скрипт сразу завершится, то ничего толкового мы не получим. Реалиация ожидания зависит в первую очередь от применения модуля в реальном проекте, сейчас же можно просто сделать костыль:

Ждем событий изменений ФС до прихода Ctrl+C (SIGINT), после чего говорим нашему потоку завершиться и ждем, пока он это выполнит.

Запускаем скрипт, идем по нашему пути и:

На выходе скрипта имеем:

В методы нашего класса Handler в поле event приходят потомки FileSystemEvent, перечисленные в watchdog/events.py.
У всех есть свойства src_path, is_directory, event_type («created», «deleted», и т.п.). Для события moved добавляется свойство dest_path.

Ну если вы больше ничего не хотите… А разве ещё что-нибудь есть?

PatternMatchingEventHandler можно использовать для получения событий только о тех узлах ФС, имена которых подходят по маске с правилами:

• * любые символы
• ? любой единичный символ
• [seq] любой единичный символ из указанных
• [!seq] любой единичный символ НЕ из указанных

Задание правил выполняется при создании:

RegexMatchingEventHandler делает тоже самое, но с явным указанием regexp-выражений в конструкторе:

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

Наконец, LoggingEventHandler выводит все в лог через logging.info().

— Вот и все. Может кому пригодится.

P.S.
При слежении за директорией, в которой (и в ее дочерних) содержатся папки/файлы не с ascii именованием, возникнет исключение exceptions.UnicodeEncodeError в глубинах watchdog’а. В Linux (inotify) он возникает в watchdog.observers.inotify.Inotify._add_watch.
Причина — чтение содержимого в ascii кодировке.
Для исправления ситуации можно пропатчить метод:

Вот пример исходной строки, и ее repr() до и после обработки encode():

Источник

Кунг-фу стиля Linux: наблюдение за файловой системой

Пользователи UNIX-подобных ОС, чтобы достичь желаемого результата, привыкли организовывать совместную работу различных программ, рассчитанных на решение какой-то одной задачи. Эти команды, например, помещают в файл Bash-скрипта, а потом, по своей инициативе, вызывают этот скрипт из командной строки. А что если нужно, чтобы система сама реагировала бы на какие-то изменения, действуя без вмешательства пользователя? Например, нужно организовать наблюдение за директорией и автоматически вызывать какую-то программу тогда, когда в эту директорию будет скопирован файл с использованием FTP. При этом не хотелось бы сидеть за компьютером во время передачи этого файла и ждать завершения операции.

Самый простой, но не очень-то красивый способ это сделать заключается в периодическом сканировании директории. Вот весьма примитивный скрипт, который реализует такой функционал:

В этом примере я вывожу содержимое файла в консоль и удаляю его. Но в реальной жизни с подобным файлом можно сделать что-нибудь куда более интересное. Это — пример того, как не стоит писать скрипты. Ведь скрипт всё время выполняется. К тому же, такое решение задачи нельзя назвать красивым или остроумным. (Если вы полагаете, что в данном примере мне стоило бы использовать конструкцию for I in * — попробуйте это сделать в пустой директории и вы поймёте причину использования команды ls .)

Как организовать наблюдение за файловой системой в Linux?

Более симпатичное решение задачи

Если говорить честно, то для решения нашей задачи хорошо было бы сделать нечто, выглядящее лучше вышеприведённого примера. В современных ядрах (начиная с 2.6.13) есть механизм уведомлений о событиях файловой системы, представленный интерфейсом inotify . Соответствующие вызовы можно использовать программно, применяя заголовочный файл sys/inotify.h . Существует и набор инструментов командной строки, который можно установить, обычно представленный пакетом inotify-tools .

Один из инструментов этого пакета, inotifywait , позволяет улучшить код нашего примера. Скажем, переделать код можно так:

Я думаю, что этот вариант лучше предыдущего. Скрипт вызывается не через заданные промежутки времени, а только тогда, когда в файловой системе что-то произошло. Я полагаю, что любая нормальная программа, воздействующая на файлы, находящиеся в директории, либо открывает файлы для записи и закрывает их после завершения операции, либо перемещает файлы в директорию. Наша программа отреагирует на оба эти события, а благодаря %f команда сообщит имя файла. Есть, конечно, и другие события, за которыми можно наблюдать.

Если вас интересует вопрос о том, почему необходимо наблюдать за событием перемещения файла, подумайте о том, как работает большинство текстовых редакторов и программ для загрузки файлов по сети. Обычно новому файлу не дают постоянного имени до тех пор, пока не завершится его обработка. Например, Chrome будет загружать файл с именем test.txt , дав ему временное имя test.txt.crdownload (или имя, подобное этому). Файл будет переименован (перемещён) в файл test.txt только после завершения загрузки.

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

Исследование команды inotifywait

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

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

Новый cron

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

Для решения нашей задачи можно воспользоваться и ещё одной программой, называемой incron (я почти уверен в том, что вам эта программа пригодится, и что её стоит установить). Эта утилита похожа на cron , но вместо того, чтобы выполнять какие-то действия, ориентируясь на события, связанные с временем, она ориентируется на события, связанные с файлами. После её установки вам, вероятно, если вы планируете ей пользоваться, стоит отредактировать файлы /etc/incron.allow и /etc/incron.deny . Особенно — если вы будете применять её, работая как обычный пользователь.

Предположим, нам надо выполнять некий скрипт в том случае, если в директории hexfiles появится какой-нибудь файл. Для редактирования таблицы событий, за которыми наблюдает incron , можно воспользоваться командой incrontab -e . Данные, вносимые в эту таблицу, представляют собой описания задач и по-особенному форматируются. В частности, тут для разделения столбцов используются не знаки табуляции, а пробелы. Вот строка, которая позволяет решить вышеописанную задачу:

Конструкция $@/$# в конце этой строки позволяет получить полный путь к файлу, на событие, произошедшее с которым, отреагировала программа. Тут, кроме того, можно получить время возникновения события — либо в виде текста ( $% ), либо в виде числа ( $& ). С помощью incron можно наблюдать за обычными событиями. Утилита, кроме того, поддерживает различные опции. Например, можно не разыменовывать символические ссылки. Подробности об incron ищите в справке к утилите.

Настройка incron с использованием графического интерфейса

Я — не большой любитель Linux-инструментов с графическим интерфейсом, но я знаю, что многим они нравятся. Если вы — из их числа — вот incrontab-редактор, написанный на Java. Нельзя сказать, что этот проект отличается подробной документацией, но его использование упрощает то, что в него можно импортировать файл incrontab . Если он у вас есть — ищите его по пути /var/spool/incron/your_user_id . Если посмотреть на окно редактора, показанное ниже, можно заметить, что он позволяет упростить создание incron-таблицы.

Графический интерфейс для incron

Обычно системные файлы можно найти в /etc/incron.d . Пути расположения файлов можно задавать в файле /etc/incron.conf . Поэтому, если вам нужно поменять место расположения файла таблицы, но вы не знаете о том, где его искать, загляните в этот файл.

Итоги

Использование incron выглядит как очень аккуратное решение задачи мониторинга файловой системы. Системная программа берёт на себя заботу о наблюдении за событиями файловой системы, а скрипт запускается лишь тогда, когда это нужно. Кроме того, используя эту программу, можно легко узнать о том, за чем именно организовано наблюдение. В результате incron — это инструмент, с помощью которого можно сделать куда больше, чем наблюдение за текущей папкой в открытом окне терминала.

Источник