Запустить что-то, когда USB-устройство подключено, не работает

Я сделал скрипт в /etc/udev/rules.d/local.rules

SUBSYSTEM=="usb", SYSFS{idVendor=="b58e"}, SYSFS{idProduct=="9e84"}, ACTION=="add", RUN+="notify-send USB"

Затем я перезагружаю udev с помощью

 sudo udevadm control --reload-rules

Я попытался удалить все, кроме подсистемы и запустить. Я пробовал запускать '=' вместо '+=', надоел ATTR вместо SYSFS. Я пробовал «перезагрузка sudo service udev» и «перезагрузка sudo udev». Я отключаю устройство, затем снова подключаю его, и оно не запускает действие. Я попытался переименовать его в 70-local.rules и изменить права доступа на a+x. Я попытался изменить «подсистему» ​​на «шину». Я попытался установить run как «/path/test.sh», который имеет ту же команду.


ubuntu linux usb udev kubuntu
person ForeverConfused    schedule 02.07.2012    source источник

Ответы (2)


arrow_upward
11
arrow_downward

Я не эксперт, и это не ответ, но я нашел следующие шаги полезными для определения соответствующих атрибутов для запуска:

  1. Найдите путь к устройству с помощью udevadm, lsusb или usb-devices. Обычно я просто использую lsusb и позволяю завершению табуляции в моей оболочке вести меня. В моем случае путь /dev/bus/usb/003/007.
  2. Используйте udevadm для определения атрибутов устройства для записи правил. В моем случае я использовал udevadm info -a --attribute-walk --root --name=/dev/bus/usb/003/007.
  3. Напишите правило и проверьте, срабатывает ли оно. В моем случае я просто меняю владельца устройства на пользователя «Стивен», и мне очень легко проверить, работает ли оно, используя ls -l /dev/bus/usb/003/007. Мое правило для этого случая выглядит так: SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", OWNER="stephen". У меня есть похожее правило, которое меня немного озадачило, потому что подсистема ожидала ATTRS, а не ATTR, поэтому я рекомендую пройтись по атрибутам. Правило в этом последнем случае стало таким: `SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", OWNER="stephen".

И, конечно же, man udev всегда поможет. Как вы сказали, вы должны изо всех сил пытаться определить, правильно ли срабатывает ваше правило, и, возможно, лучше всего просто быстро сменить владельца на устройстве, как я сделал для первого шага. Иногда вы можете столкнуться с проблемами из-за плохих атрибутов или символических ссылок, и это

person Stephen Niedzielski    schedule 03.07.2012
comment
Для меня это был ATTR, а в правилах udev указано, что команда RUN принимает на вход программный файл. Он должен быть помечен как исполняемый и должен иметь #! вверху, если это интерпретируется. Групповая вещь заставила понять, что это работает, но запуск был неправильным. Это, наконец, сработало. Спасибо! - person ForeverConfused; 03.07.2012

arrow_upward
3
arrow_downward

он не запускает действие

Нет, он запускает действие. Проблема в том, что он не знает, куда отправить уведомление, так как при запуске udev не работает инфраструктура уведомлений. Вам нужно будет отправить сообщение DBus по системной шине, а пользовательский демон перехватит сообщение и вместо этого отправит уведомление.

person Ignacio Vazquez-Abrams    schedule 02.07.2012
comment
Спасибо. Я изменил файл, чтобы он содержал только SUBSYSTEM==usb, ACTION==add, RUN=echo 1 › /tmp/foo. Однако файл, похоже, не создается. Я пробовал с SYSFS или без него. - person ForeverConfused; 03.07.2012
comment
Теперь он повторяет 1 › /tmp/foo. - person Ignacio Vazquez-Abrams; 03.07.2012
comment
Я пробовал [SUBSYSTEM==usb, ACTION==add, RUN=touch /tmp/asdfg] с вариациями run [RUN=gimp] [RUN=echo '1' › /tmp/foo] перезагружался всеми возможными способами. Все равно не повезло. Udev говорит: «udev start/running, process 5038» при перезапуске, поэтому я знаю, что он запущен. Есть ли способ подтвердить, что он берет мой файл конфигурации, или заставить его выдавать ошибки, если он не может их проанализировать? - person ForeverConfused; 03.07.2012