Почему этот udev не управляет триггером после демонтажа устройства?
Существует исключение, которое будет детализировано позже, но те команды выполняются той же оболочкой (даже если Myscript открывает новую оболочку, это и command D будет обладать точно той же "родительской" оболочкой, которая выполняет их). Поскольку *ОТКЛОНЯЮТ оболочки, не поддерживают распараллеливание, Myscript должен остановиться его выполнение (с любыми кодами выхода) для разрешения управлению продвинулось command D.
Исключение имеет место, где Вы отсоединяетесь Myscript, с a NOHUP сигнал, или путем записи a & позади Myscript. Это поместит сценарий в фон.
Изучите следующий фрагмент кода:
openssl enc -e bf -in verybigfile -out outputfile -k thisismykey &; # this is a long operation because of the size of the very big file
echo 'hi!' # this will be written during the encrypting operation
Я надеюсь, что это почти очевидно теперь.
Ответ Alexios содержит большую точку: Вы не вызываете функцию, таким образом, она никогда не будет работать.
Альтернативное решение
После окончания записи рева ответа я понял, что то, чего Вы пытаетесь достигнуть, могло быть выполнено намного более изящно с помощью xinput или даже использование конфигурации Xorg. Удостоверьтесь, что прочитали документацию об управлении устройствами ввода данных в Xorg.
Используя udev (ответ на Ваш вопрос)
Согласно моим тестам существует две проблемы с Вашими правилами:
- По крайней мере, на моем GNU/Linux Ubuntu 12.04, никакие проверки на
ENV{DEVTYPE}когда-либо соответствие (даже при том, что этим сообщают правильноudevadm infoиudevadm monitor). Это - основания, которые Вы даже не видитеaddподбор правила. - Необходимо удалить
OWNERприсвоение отremoveправило. Это не имеет смысла, и udev игнорирует правило в целом.
Попробуйте следующими двумя правилами и посмотрите, решают ли они проблему.
ACTION=="add", ENV{ID_MODEL}=="USB_Receiver", ENV{ID_VENDOR_ID}=="046d", ENV{ID_MODEL_ID}=="c51a", RUN+="/home/user/.scripts/Troubleshooting/Bugfixes/mouseswitcher_wrapper 1", OWNER="user"
ACTION=="remove", ENV{ID_MODEL}=="USB_Receiver", ENV{ID_VENDOR_ID}=="046d", ENV{ID_MODEL_ID}=="c51a", RUN+="/home/user/.scripts/Troubleshooting/Bugfixes/mouseswitcher_wrapper 0"
Дополнительные соображения
Несколько вещей рассмотреть:
- это намного более чисто для использования
ATTR{idVendor}иATTR{idProduct}для классификации устройств. Можно безопасно изменитьсяaddправило использовать их, вместоENV, но я оставил их как это ради простоты. В настоящее времяaddиremoveправила почти идентичны. - Рассмотрите последствия безопасности запущения скрипта как корень в каталоге, который перезаписываем другими пользователями. В Вашем особом случае это не серьезная проблема, но я не назвал бы это хорошей практикой безопасности. IMO это намного лучше поместило бы сценарий в/usr/local/bin/, делая принадлежавшим root.root и режиму 0755.
- Удостоверьтесь, что Вы хотите, чтобы устройство мыши принадлежало Вашему пользователю, нет действительно никакой потребности в этом, PolicyKit и Xorg должны смочь обработать корневые устройства без любых проблем.
Если Вы не должны изменять владельца устройства и Ваших работ установки с корневым устройством, то Вы могли упростить свои два правила udev до этого:
ACTION=="add|remove", ENV{ID_MODEL}=="USB_Receiver", ENV{ID_VENDOR_ID}=="046d", ENV{ID_MODEL_ID}=="c51a", RUN+="/home/user/.scripts/Troubleshooting/Bugfixes/mouseswitcher_wrapper $env{ACTION}"
Это назовет Ваш сценарий с соответствующим действием - remove или add, таким образом, необходимо будет изменить сценарий для обработки этих аргументов.
Для предотвращения правила соответствовать (и сценарий для выполнения) несколько раз, необходимо сделать правило более конкретным: правило соответствует для каждого "входа" (кнопки, и т.д.) мыши. Вот почему это неоднократно выполняется. Попытайтесь добавить ENV{ID_TYPE}!="hid" или ENV{ID_USB_DRIVER}!="*hid*" и посмотрите, работает ли это, поскольку существует только одно устройство, которое не является HID - вершина usb_device.
PS: Если Вы хотите сделать Ваш mouseswitcher более гибкий сценарий, и выполняет систему с ConsoleKit, Вы могли использовать ck-list-sessions получить пользователя, который в настоящее время зарегистрирован и использует ту информацию для установки XAUTHORITY переменная.
Прошло несколько лет с тех пор, как был написан предыдущий ответ. Похоже, что с тех пор udev изменился, так что решение udev больше не работает, по крайней мере, для Ubuntu 18.04 с пакетом udev версии 237 -3ubuntu10.29. Я публикую этот ответ для тех, кто столкнется с этой проблемой в будущем, поскольку я не нашел других отчетов об этой проблеме.
В этой версии udevENV{ID_VENDOR_ID}ENV{ID_MODEL_ID}не установлены для событий удаления, поэтому правила для этих переменных никогда не будут совпадать. Обходной путь — использовать ENV{PRODUCT}, который установлен как для событий добавления, так и для удаления. ENV{PRODUCT}имеет вид idVendor/idProduct/bcdDevice, поэтому ему можно сопоставить правило, содержащее:
ENV{PRODUCT}=="xxxx/yyyy*"
, где xxxx— идентификатор производителя, а yyyy— идентификатор продукта вашего устройства.
Дополнительное примечание, по сравнению со временем предыдущего ответа, заключается в том, что udev теперь правильно устанавливает ENV{DEVTYPE}, и это может быть сопоставлено в правилах.
info. – Glutanimate 08.04.2013, 03:17ENV{ID_TYPE}!="hid"илиENV{ID_USB_DRIVER}!="*hid*"и посмотрите, работает ли это. – zorlem 08.04.2013, 04:00ENV{ID_TYPE}!="hid"хорошо работавший.Спасибо! – Glutanimate 08.04.2013, 04:33udevто движение вне высказывания "просто добавляетENV{DEVTYPE}=="usb_device"к Вашим правилам", но также и объясняют почему.Спасибо! вывод – Dmitry Grigoryev 22.10.2015, 13:30