☰

Die neue udev-"Philosophie"

tag-icon • tag-icon 13.04 udev xinput
Die neue udev-"Philosophie"

Hier ist eine Regel aus meinem /lib/udev/rules.dVerzeichnis:

SUBSYSTEM=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="008c", RUN+="/home/mikeknoop/scripts/udev-receiver.sh"

Hier ist der einfache Inhalt des udev-receiver.shSkripts:

#!/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

Wenn ich mein Gerät anschließe, external.logist die Ausgabe wie erwartet:

UDEV-RECEIVER INIT
UDEV-RECEIVER FINISH
Done

Ich verfolge jedoch auch das Syslog und kann sehen, dass die Geräteinitialisierung blockiert ist, bis „after“ in meiner Datei angezeigt wird , /var/log/syslogobwohl ich den lang laufenden sleepProzess aufgespalten habe.udevDoneexternal.log

Der Grund, warum dies wichtig ist, liegt darin, dass ich versuche, einige Geräteeigenschaften über festzulegen, xinputdas Gerät jedoch erst über aufgelistet wird, xinput listwenn die gesamte udevInitialisierung abgeschlossen ist (bis danach Donein angezeigt wird external.log).

Entsprechend derudev(7) - Linux-Manpage

„Fügen Sie ein Programm zur Liste der Programme hinzu, die für ein bestimmtes Gerät ausgeführt werden sollen. Dies kann nur für sehr kurz laufende Aufgaben verwendet werden. Das Ausführen eines Ereignisprozesses über einen längeren Zeitraum kann alle weiteren Ereignisse für dieses oder ein abhängiges Gerät blockieren. Lang laufende Aufgaben müssen sofort vom Ereignisprozess selbst getrennt werden.“

Ich kann die Manpage und das Verhalten, das ich sehe, nicht in Einklang bringen. Kann jemand Licht ins Dunkel bringen oder eine bessere Möglichkeit anbieten, Eigenschaften festzulegen, xinputwenn ein Gerät eingefügt wird?

Danke!

Antwort1

Ich beantworte meine eigene Frage nach vielen weiteren Recherchen.

Die neue udev-"Philosophie"

Offensichtlich besteht die neue „richtige“ Verwendungsweise udevdarin, keine Prozesse mit langer Laufzeit zu verursachen.

Überhttp://blog.fraggod.net/2012/06/16/proper-ish-way-to-start-long-running-systemd-service-on-udev-event-device-hotplug.html:

RUN ... Das Starten von Daemons oder anderen Prozessen mit langer Laufzeit ist für udev nicht geeignet. Die gegabelten Prozesse, ob getrennt oder nicht, werden nach Abschluss der Ereignisbehandlung bedingungslos beendet.

Beachten Sie, dass dies im Widerspruch zur Manpage-Angabe im OP steht.

Meine beste Vermutung ist, dass eine kürzliche udevÄnderung (irgendwann 2012) alle Prozesseeinschließlichihre gegabelten Kinder müssen fertig sein, bevor die Ausführung als Durchsetzungsmechanismus für diese neue Philosophie fortgesetzt werden kann.

Daher sind jetzt alle leicht zugänglichen Dokumentationen und Antworten im Web defekt, die das Muster im OP als Lösung angeben.

Die neue Philosophie des Langzeitmusters ist verständlich, wenn von einem Daemon die Rede ist, der immer ausgeführt wird, wenn das Gerät angeschlossen ist. Allerdings macht sie deferdamit auch den effektiven Anwendungsfall zunichte.

Problemumgehung

Trotzdem habe ich auch einen Workaround entdeckt:

/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

NotizDies wurde getestet und funktioniert auf Ubuntu 13.04

NotizSie müssen atein asynchrones Task-Paket installieren übersudo apt-get install at

Ich habe den Workaround aushttps://unix.stackexchange.com/questions/28548/how-to-run-custom-scripts-upon-usb-device-plug-in

verwandte Informationen