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.

Источник

Слежение за изменениями в директории: как это делается в разных ОС

Для операционной системы Windows есть замечательная функция ReadDirectoryChangesW, которая возвращает набор изменений для директории, в том числе содержит флаг для работы рекурсивно (bWatchSubtree). Таким образом, реализация слежения за изменениями в директории не представляет особого труда и в том же dklab_realsync реализация занимает 80 строк кода или 3.5 Кб. Интересно, что в Windows эти события поддерживаются даже через SMB!

Тем не менее, существуют определенные подводные камни:

• конечный размер буфера изменений, после которого очередь событий переполнится и эти события будут потеряны
• согласно документации к watchdog package, событие перемещения посылается раньше, чем изменения становятся видны в ФС
• размер буфера ограничен в 64 Кб для сетевой ФС

Вывод: Функция ReadDirectoryChangesW позволяет легко узнавать обо всех событиях в файлах, но, очередь событий может переполниться и тогда нужно будет выполнять полное сканирование ФС. Также, возможна доставка событий до того, как они станут актуальны.

Mac OS X, FSEvents

В Mac OS X также есть удобный и простой API для слежения за изменениями в файловой системе под названием FSEvents. С использованием этого API простейшая реализация демона составляет 50 строк кода или 1.8 кб. Очередь не может переполниться (!), но полное сканирование все же может потребоваться, если демон fseventsd «упадет». Стоит отметить, что этот API до версии 10.7 не предоставляет изменения по файлам, он сообщает только директории, в которых что-то изменилось. Поскольку события никуда не деваются и пишутся в лог (FSEvents service stores events in a persistent, per-volume database), детализация с точностью для директории позволяет сэкономить место на диске.

Вывод: FSEvents API для Mac OS X является самым необычным из всех подобных API. Очередь не переполняется и даже имеется возможность получить события из прошлого. Тем не менее, детализация событий дается с точностью до директории (до версии 10.7), что означает меньшую эффективность демона для синхронизации файлов.

Linux, inotify

В linux vanilla kernel существует один способ слежения за изменениями в директории — это inotify. Для этого API существует хорошая и подробная документация, но нет поддержки рекурсивного слежения за изменениями! Также, у inotify есть ограничение на максимальное количество объектов, за которыми можно следить. Простейшая реализация демона занимает уже 250 строк кода или 8 кб. Статическая сборка с использованием dietlibc занимает примерно 14 кб. Другим неприятным моментом является то, что приложение должно само поддерживать соответствия между watch descriptor (в нашем случае это всегда директория) и именем. Есть функция inotify_add_watch, которой передается путь до отслеживаемой директории, но нет обратной — inotify_get_path, которая бы возвращала этот самый путь по переданному дескриптору. События же содержат только watch descriptor и относительный путь до изменившегося файла внутри директории.

Подводные камни рекурсивного слежения за директорией через inotify:

• Возможность переполнения очереди (длина очереди задается в /proc/sys/fs/inotify/max_queued_events)
• Ограничение на максимальное количество объектов слежения (задается в /proc/sys/fs/inotify/max_user_watches)
• Отсутствие возможности рекурсивного слежения за директорией
• Необходимость отдельно обрабатывать случай, когда создается директория (например mkdir -p a/b/c). Вы получите событие о том, что создана директория «a», но пока вы навешиваете обработчик на эту директорию, в ней уже могут создать ещё одну директорию и событие об этом вам уже не придет.
• Теоретическая возможность целочисленного переполнения watch descriptor (wd), так как он задается uint32

FreeBSD, Mac OS X, kqueue

FreeBSD и Mac OS X позволяют отслеживать за изменениями с помощью kqueue, который аналогичен inotify по своим характеристикам и также не имеет возможности рекурсивного слежения за директориями. Также, kqueue принимает в качестве аргументов дескрипторы открытых файлов (директорий), поэтому при использовании этого API ограничения на количество отслеживаемых директорий ещё более строгие.

Источник

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

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

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

Как и во многих других случаях, в Unix-подобных системах есть инструменты для решения вышеописанной задачи. И, что неудивительно, таких инструментов существует довольно много. Если вы, например, пользовались командой tail , то вы уже видели один из таких инструментов. Но tail — это лишь вершина айсберга.

Давайте рассмотрим пример анализа файла, который можно назвать «матерью всех логов». Это — /var/log/syslog . Попробуйте вывести его на экран с помощью команды cat или less (я, в своих системах, всегда создаю псевдоним more для команды less , поэтому если я вдруг упомяну команду more — знайте, что я имею в виду less ). Этот файл, вероятнее всего, будет очень большим, его размеры будут постоянно расти. В обычной настольной системе он ведёт себя довольно спокойно, но в некоторых старых системах и на серверах в нём можно увидеть последствия бурной деятельности разных программ. В любом случае, за исключением тех ситуаций, когда система только что загружена, в нём будут многие страницы данных.

Хакерский подход к анализу логов

Поиск информации, которая уже присутствует в этом файле, особых сложностей не вызывает. Тут можно воспользоваться grep , или можно загрузить копию файла в текстовый редактор. Проблема заключается в анализе свежей информации. Попробуйте подключить USB-устройство к системе (или отключите его от неё). Вы увидите, как в syslog появились новые записи. А что если в него постоянно добавляются десятки сообщений? Как за ними уследить?

И эта проблема характерна далеко не только для файла syslog . Например, интересно может быть наблюдать за файлом листинга в ходе выполнения долгой компиляции кода. То же относится и к наблюдению за перестроением RAID-массива. В общем-то, в Linux всегда можно найти некий большой файл, постоянно пополняемый свежими сведениями, за которым нужно понаблюдать.

Команда tail

Традиционный подход к наблюдению за файлами, постоянно пополняемыми информацией, заключается в использовании команды tail . Она берёт большой файл и возвращает лишь некоторое количество его последних строк. Эту команду можно вызвать с опцией -f . Тогда она будет ждать появления в файле новых данных и выводить их. Эта опция весьма полезна для наблюдения за файлами, в которые постоянно добавляется что-то новое. Опция -F приводит к практически такому же эффекту, но благодаря ей tail , если не может сразу открыть файл, будет продолжать пытаться открыть его. С помощью опции -m можно задавать количество выводимых последних строк файла, а с помощью опции -c — количество байтов. Опция -s позволяет задавать частоту проверки изменений файла.

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

Вы увидите несколько строк из конца файла системного журнала. А если подключить к компьютеру USB-устройство или отключить такое устройство от компьютера, можно увидеть, как сведения, попавшие в журнал, практически мгновенно выводятся на экране. Повторно запускать tail при этом не нужно.

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

Меньше — значит больше: полезные возможности команды less

У команды less есть опция +F , которая превращает эту команду в хорошую замену команды tail . На самом деле, если вы испытаете команду, приведённую ниже, вас может посетить мысль о том, что результаты её работы не очень-то и отличаются от результатов работы tail . Вот эта команда:

Вот как вывод этой команды выглядит на моём компьютере.

Результаты работы команды less

Обратите внимание на то, что в нижней части экрана имеется надпись Waiting for data… . В данный момент утилита less работает практически так же, как и tail . Но если нажать CTRL+C — произойдёт кое-что интересное. Ну — что-то, возможно, и произойдёт. Попробуйте. Если less переходит в командный режим — значит всё в порядке. Теперь можно заниматься всем тем, чем обычно занимаются, просматривая файлы с помощью less . Если же по нажатию CTRL+C работа less прекратится, это будет означать, что ваш Linux-дистрибутив «помог» вам, установив некоторые стандартные опции less с использованием переменной окружения LESS . Попробуйте такую команду:

Если вы увидите, что в списке опций имеется —quit-on-intr , это будет значить, что проблема заключается именно в данной строке. Её надо убрать. После этого переключиться в командный режим можно с использованием CTRL+C . Это, кроме того, означает, что вам нужно запомнить, что для выхода из less используется команда q . Если вы вышли из режима наблюдения за файлом и хотите снова в него вернуться — просто нажмите F .

Если вы пользуетесь less в обычном режиме (то есть — не использовали при запуске утилиты опцию +F ), вы можете нажать клавишу F на клавиатуре для перехода в «tail-режим». А ещё интереснее то, что, нажав ESC-F можно в этом режиме что-то искать, при этом, если в поступающих данных найдётся совпадение с тем, что вас интересует, система вам об этом сообщит.

Команду less можно ещё использовать с ключом —follow-name . Это позволит добиться того же эффекта, что и использование опции -F команды tail .

Наблюдение за файлами с помощью команды watch

Иногда файл, за которым нужно наблюдать, не пополняется новыми данными, добавляемыми в его конец, а просто иногда меняется. Например, это файл /proc/loadavg или многие другие файлы из директории /proc . Использование команд tail или less не особенно хорошо подходит для наблюдения за такими файлами. Тут нам на помощь придёт команда watch :

Результат выполнения команды watch

Эта команда вызывает cat каждые 5 секунд и аккуратно выводит результат. Команда watch поддерживает множество полезных опций. Например, опция -d позволяет выделять отличия, а -p позволяет задействовать высокоточный таймер. Опция -c включает поддержку цвета.

Использование текстового редактора для наблюдения за файлами

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

Если вы не ищете лёгких путей, то вам, возможно, подойдёт инструмент наподобие lnav, который сделан специально для просмотра логов. Просмотрщики журналов имеются, кроме того, в KDE и Gnome.

Итоги

Как это обычно бывает в Linux и Unix, у задачи организации наблюдения за файлами есть множество решений. Какое из этих решений «лучше» других? У каждого будет собственный ответ на этот вопрос. Именно это и делает Linux системой, привлекательной для продвинутых пользователей. Каждый из них может выбрать именно то, что подходит ему лучше всего.

Те команды, о которых мы говорили, могут пригодиться и тем, кто пользуется настольным дистрибутивом Linux, и тем, кто работает с серверами или с Raspberry Pi.

Как вы наблюдаете за постоянно изменяющимися файлами в Linux?

Источник