А не проще сделать это через udev? Всяко прямее.

Как через udev отловить событие монтирования? Я описал как пытался, у меня не удалось. Если модскажете ЧЯДНТ - буду благодарен

1) Переименовать /bin/mount в /bin/mount.org, в /bin/mount положить свой скрипт-враппер;
2) Мониторить в цикле изменение /proc/mounts (кстати, такое уже есть: findmnt --poll).

Просто настрой монтирование флешек средствами udev, а не через udisks или что-либо ещё.

1) Переименовать /bin/mount в /bin/mount.org, в /bin/mount положить свой скрипт-враппер;

Костыльно слишком. Не вариант

2) Мониторить в цикле изменение /proc/mounts (кстати, такое уже есть: findmnt --poll).

Уже копаю в эту сторону, но никак не могу отловить с помощью питона изменение в /proc/mounts или /etc/mtab ни QFileSystemWatcher ни inotify не работают.

тоже костыльно и совсем не универсально, не вариант подпиливать систему под простецкий скрипт.

Ну с /proc наверное inotify и не должен работать? А с /etc странно..
А если сорцы findmnt посмотреть? Как они делают?

Судя по беглому обзору https://github.com/karelzak/util-linux/blob/master/misc-utils/findmnt.c эьти ребята просто с какм-то таймаутом просматривают /etc/mtab и дифят его. Это конечно сработает, но как-то до расстройства несерьёзно.

Потому что /etc/mtab обычно ссылка на /proc/self/mounts. Соответственно, inotify работать не будет

Вот мои попытки добиться отлова монтирования https://github.com/alexkutsan/USBBackup Пока безрезультатно

Есть ли у вас мысли как рещить проблему?

Я не привередливый, я бы тупо парсил выхлоп findmnt.

Моя идеалистическая натура хочет сделать production quality. Чтоб не стыдно было на github выкинуть, чтоб люди пользоваться могли.

парси логи ( /var/log/messages ), там их уже отловили.

Посмотри еще в строну audit и перехвата mount syscall.
Или допили udev до понимания mount event (сейчас там только connect/disconnect) и выложи патчи на github.

Бесит!

Прям пичаль-бида.

Я теперь понимаю почему в моём несчастном ArchLinux всё работает через жопу или не работает вообще. Даже такая простая задача как повесить хук на монтирование флешки превращается в парсинг логов или допиливание udev, или циклическое чтение файла и сравнение с предыдущим состоянием или парсинг вывода утилиты командной строки с отдельного подпроцесса. Костыли, велосипеды и ничего нельзя сделать ровно... Бесит, наболело.

Попробуй слушать dbus-события активации новых юнитов с именем *.mount.

Когда я манчу девайс с помощью mount всё что я вижу в dbus мониторе это http://hastebin.com/inadehimiz.vbs

У меня вот так: http://ix.io/1kl6

Там почему-то возникают мусорные события (PropertiesChanged на юнитах разделов, которые никто не трогал), но монтирование tmpfs на /mnt/test тем не менее вполне видно.

Другой вопрос, что это непарсибельно. Насколько мне известно, шелл-френдли утилит для ловли D-Bus сигналов не существует. С другой стороны, напиши, опенсорс тебя не забудет =)

Ещё можно слушать udisks, если он у тебя есть (org.freedesktop.UDisks2).

Хотя там всё ещё более непарсибельно: точки монтирования энкодятся как массивы байт (ay), а не как строки (s).

На разборки с тем, как через dbus монтировать/демонтировать и делать прочую хрень без всяких glib и прочей шняги в свое время пришлось потратить некоторое время. Теперь могу с этим работать в чистом Си (ну плюс libdbus естественно). Но я так понял это не вариант, так как нужно делать это через скрипт.

А вот насчет того, как отследить простой факт монтирования/демонтирования, то делается это весьма занимательным образом. Если мне не изменяет память, то через inotify отслеживается /proc/mounts (или что там у нас в /proc за это дело отвечает). Но весь нюанс в том, что так как это виртуальная фс, то отслеживать надо событие связанное с ошибкой на дескрипторе. Она свидетельствует о том, что файл обновился. Как то так. Подробнее можно посмотреть исходники udisks.

Выполнил ту-же команду с dbus-monitor. И примонтировал с помощью

sudo mount /dev/sdb1 /mnt

Вывод схож. Но никакого упоминания про /mnt я не нашел http://pastebin.com/2iji7yXq

Я слушал udisk https://github.com/alexkutsan/USBBackup/blob/master/mount_detector.py И оно даже работает при условии, что монтируется в /usr/media

Там почему-то возникают мусорные события (PropertiesChanged на юнитах разделов, которые никто не трогал), но монтирование tmpfs на /mnt/test тем не менее вполне видно.

Я не нашел где оно видно. Можете показать?

Может и через Си был бы вариант, если написать на Си демон, который будет монирить DBus и запускать скрипт. Звучит не сложно. Но нужно не монтировать\демонтировать, а отслеживать события монтирования. Я постараюсь вникнуть в исходники с udisks и отследить как они это делают, как вы говорите с помошью трюка с ошибкой на дескрпторе. Звучит конечно костыльно, но менее костыльно чем парсить логи или подменять mount или читать /proc/mounts каждую секунду.

Сейчас попробовал ручками смонтировать и отмонтировать флэшку в /mnt. Моя программулина, работающая с Udisks2, показала, что флэшка примонтировалась и отмонтировалась.

Сигналы serial=8701 и serial=8702.

Поделитесь кодом?

Сигналы serial=8701 и serial=8702.

Я вижу, что произошло монтирование файловой системы tmpfs, но не вижу куда они примонтировалась, как из этих сообщения достать /mnt/test ?

В своём логе http://pastebin.com/ я могу тооже обнаружить, что примонтировалось устройство

 variant             string "/dev/sdb1"

Но может ли мне кто-то объяснить, что это за юнит mnt_2emount? Который генерирует эти DBus сигналы? Это часть ядра? Или какого-то пакета? Так-же ли это работает к примеру в убунте или федоре?

Юнит — это абстрактная сущность в рамках systemd. В данном случае юнит описывает появившуюся точку монтирования. Путь до неё можно достать из имени:

mnt_2dtest_2emount -> mnt-test.mount -> /mnt/test

На первом шаге нужно заменить _xx на символы с кодом xx, а на втором шаге нужно убрать суффикс .mount и применить systemd-escape --path --unescape (почитай ман по этой команде).

https://sourceforge.net/projects/xmsvm/?source=directory