Почему это правило udev блокирует?
Вот правило из моего каталога /lib/udev/rules.d:
SUBSYSTEM=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="008c", RUN+="/home/mikeknoop/scripts/udev-receiver.sh"
Вот простое содержание скрипта udev-receiver.sh:
#!/bin/bash
echo "UDEV-RECEIVER INIT" >> /var/log/external.log
{
sleep 5;
echo "Done" >> /var/log/external.log
} &
echo "UDEV-RECEIVER FINISH" >> /var/log/external.log
Когда я подключаю свое устройство, вывод external.log будет таким, как вы ожидаете:
UDEV-RECEIVER INIT
UDEV-RECEIVER FINISH
Done
Тем не менее, я также слежу за системным журналом /var/log/syslog и вижу, что, хотя я раздвоил длинный - в процессе sleep инициализация устройства udev блокируется до тех пор, пока Done не появится в моем файле external.log.
Причина, по которой это важно, в том, что я пытаюсь установить некоторые свойства устройства через xinput, но устройство не отображается в списке через xinput list, пока не будет завершена полная инициализация udev (пока не появится Done в external.log).
В соответствии с страницей руководства udev (7) - Linux
«Добавить программу в список программ, которые будут выполняться для конкретного устройства. Это может быть только используется для очень коротких задач. Выполнение процесса события в течение длительного периода времени может заблокировать все дальнейшие события для этого или зависимого устройства. Долгосрочные задачи должны быть немедленно отсоединены от самого процесса события. "
Я не могу согласовать страницу руководства и поведение, которое вижу. Кто-нибудь может пролить свет или предложить лучший способ установки свойств через
xinput, когда устройство вставлено?Спасибо!
1 ответ
Ответ на мой собственный вопрос после большого дальнейшего исследования.
Новая udev "философия"
По-видимому, новый "надлежащий" способ использовать udev не должен подвергаться продолжительным процессам.
ВЫПОЛНЕННЫЙ... Начинающие демоны или другие длительные процессы не подходят для udev; разветвленные процессы, отсоединенные или нет, будут безусловно уничтожены после того, как обработка событий закончилась.
Отметьте, как это в противоречии с цитатой страницы справочника в OP.
Мое лучшее предположение является недавним udev изменение (~2012 когда-то) вынуждает все процессы включая их разветвленных детей закончиться прежде, чем позволить выполнению продолжаться как механизм осуществления для этой новой философии.
Поэтому вся легкодоступная документация и ответы в сети, которые дают шаблон в OP как решение, теперь повреждаются.
Новая продолжительная философия шаблона понятна в экземпляре, когда Вы говорите о некотором демоне, который всегда работает, когда устройство включается. Однако, стирает эффективное defer пример использования наряду с ним.
Обходное решение
Тем не менее, я также обнаружил обходное решение:
/lib/udev/rules.d/98-mouse-config.rules/
SUBSYSTEM=="usb", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="008c", ACTION=="add|remove", ENV{ID_TYPE}!="hid", RUN+="/home/mikeknoop/scripts/udev-receiver.sh"
udev-receiver.sh
#!/bin/bash
echo /home/mikeknoop/scripts/mouse.sh | at now
mouse.sh
#!/bin/bash
sleep 3;
export DISPLAY=":0.0"
export XAUTHORITY="/home/mikeknoop/.Xauthority"
/usr/bin/xinput --set-prop 'pointer:Microsoft Microsoft Wireless Optical Mouse® 1.0A' 'Device Accel Constant Deceleration' 2.00000
... more xinput rules here
Обратите внимание, что Это было протестировано и работы над Ubuntu 13.04
Обратите внимание, что необходимо будет установить at который является асинхронным пакетом задачи через sudo apt-get install at
Я соединил обходное решение от https://unix.stackexchange.com/questions/28548/how-to-run-custom-scripts-upon-usb-device-plug-in