Usar las reglas de udev para ejecutar un script en la inserción USB

17

Estoy tratando de configurar un script para que se ejecute cada vez que conecto un dispositivo USB. Creé el archivo /etc/udev/rules.d/90-local.rules y agregué la siguiente regla:

ACTION=="add", SUBSYSTEM=="usb", KERNEL=="sd*", SYSFS{model}=="Cruzer*", RUN+="sh /home/jesse/Documents/Scripts/cruzer.sh"

El problema es que cuando la unidad está conectada, no sucede nada. La secuencia de comandos, con fines de depuración, está diseñada para enviar una notificación con notificación-envío, que está instalada y funciona bien desde el terminal.

La ruta al script es correcta, ya que ejecuté ese comando exacto en la terminal sin ningún problema.

linux autorun udev

— JTeK
fuente

¿Se está ejecutando tu antivirus? Este es un comportamiento que desencadenaría la acción de cualquier número de programas AV. Aunque esperaría una advertencia, si ha deshabilitado las notificaciones, es posible que no la vea excepto en los registros. Recomendaría deshabilitar Internet, luego su programa AV, intentarlo nuevamente.

— zenbike

Ejecutando Ubuntu 11.04 sin AV instalado.

— JTeK

@zenbike: ¿Por qué agregar reglas personalizadas de udev desencadenaría un programa antivirus?

— user1686

Iniciar cualquier script en la inserción del dispositivo puede causar falsos positivos en un conjunto de AV para escanear dispositivos extraíbles. Por qué no lo sé. Lo que me sucedió con un script instalado de fábrica en una memoria USB y Avira AV, lo sé.

— zenbike

6

Yo tuve el mismo problema. Esto funcionó para mí:

Intente copiar su script /usr/local/biny cambiar el directorio en su .rulesarchivo.

Además, no sé qué es SYSFS, pero preferiría usar las propiedades ATTR.

La siguiente línea es el contenido de mi .rulesarchivo:

ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]1", ATTRS{vendor}=="SanDisk ", RUN+="/usr/local/bin/backup.sh"

— por favor
fuente

la ATTRS{vendor}=="SanDisk "parte quiere decir eso que sólo Sandiskse detecta?

— blade19899

7

notify-send requiere acceso a su bus de sesión DBus, que no puede tener por dos razones:

No hay información sobre la sesión. Cuando lo inicia udev, su script no sabe nada sobre dónde está conectado o si está conectado en absoluto. El asiento múltiple con X11 sigue siendo complicado, pero el cambio de usuario funciona tanto para X11 como para sesiones de consola. Muchas personas también usan SSH, VNC y NX a través de la red.

( DISPLAY=:0funcionaría la mitad del tiempo, pero eso sigue siendo adivinar en el mejor de los casos)
Negado por la política DBus. Incluso si su script de alguna manera encuentra su sesión X11, no podrá enviar notificaciones debido a que el script se está ejecutando en rootlugar de su cuenta de usuario.

— usuario1686
fuente

2

for LINE in $(find /proc/ -maxdepth 2 -name environ -exec grep -z "^DBUS_SESSION_BUS_ADDRESS" {} \; | sort -uz | tr '\0' '\n'); do eval $LINE   ... done;

hizo el truco para mí con notificar-enviar

— mlt

1

En su lugar, puede intentar hacer coincidir el dispositivo por ID de proveedor y producto. La siguiente regla personalizada funciona para mí:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0763", ATTR{idProduct}=="019b", RUN+="/usr/bin/aconnect 20 128"

Puede ver idVendor e idProduct en la salida lsusb o dmesg después de conectar el dispositivo.

— Aleh
fuente

Lo intenté y tampoco funcionó ... (ATTR {idProduct} == "5530") ... ¿también se requiere el proveedor? No lo creo ...

— JTeK

En ese caso, el problema podría estar en el script en sí. Por ejemplo, puede depender de la variable $ PATH env. Para una prueba, intente ejecutarlo como export PATH = ''; /home/jesse/Documents/Scripts/cruzer.sh

— Aleh el

1

Seguimiento de la respuesta de Aleh: si también desea monitorear removeeventos, debe buscar una variable de entorno llamada ID_SERIAL. Contiene el proveedor y la identificación del producto separados por un guión bajo:

ACTION=="add|remove", SUBSYSTEM=="usb", ENV{ID_SERIAL}=="0763_019b" RUN+="/usr/bin/aconnect 20 128"

La regla ahora es más corta también.

— krlmlr
fuente

0

Tal vez, ¿deba agregar un sleepdentro del script, para darle al dispositivo usb la oportunidad de "establecerse"? Por ejemplo, módems usb 3g, cambio de modo para obtener un / dev / ttyUSB para que el núcleo lo ponga en funcionamiento.

— t0mm13b
fuente

0

Intente reemplazar SUBSYSTEM = "usb" con SUBSYSTEMS = "usb"

— arnaud
fuente

No, SUBSYSTEM=="usb"está bien

— krlmlr