Migliorare il mio script Bash

Devo migliorare il mio script Bash in modo che funzioni perfettamente senza problemi. Questo script lo utilizza ds4drve presenta alcuni problemi che non sono sicuro su come correggere.

Il primo problema è che non viene sempre eseguito o funziona quando viene rilevato il controller, ho creato una regola udev per esso, ma non è chiaro il motivo per cui non esegue sempre questo script quando viene rilevato.

Secondo problema, ds4drvpuò essere eseguito solo come root, invece di essere eseguito come utente normale.

Terzo problema, non conosco il modo corretto di gestire i file di blocco PID dopo che sono stati creati, quindi quando il processo PID non esiste più elimina il file di blocco PID dopo. È difficile trovare la documentazione corretta su come usare i file PID negli script bash in modo che ci possa essere solo 1 istanza in esecuzione.

ecco la mia regola udev per ds4drv: 50-ds4drv.rules

KERNEL=="uinput", GROUP="users", MODE="0666"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c4", GROUP="users", MODE="0
666"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", KERNELS=="0005:054C:05C4.*", GROUP="users" MODE="0666"
ACTION=="add", SUBSYSTEM="usb", ATTRS{idProduct}=="054c", RUN+="/home/user/scripts/ds4check.sh", GROUP="users"
, MODE="0666"

Sono abbastanza sicuro che dovrebbe essere così come dovrebbe essere la regola udev, le autorizzazioni sembrano essere corrette per me dal momento che è in lettura-scrittura per gli utenti di GROUP. Sembra esserci qualche istanza di un problema che una volta eseguito il mio script bash e questa regola è impostata per essere eseguita automaticamente quando il dispositivo controller è collegato, che alcuni giochi non rispondono come se non ci fosse alcun dispositivo controller collegato quando c'è, supponiamo di agire /dev/js0ma invece di agire /dev/js1invece. Spesso può restituire questo errore in particolare se non viene eseguito come root;

OSError: [Errno 13] Permission denied: '/dev/input/event17'

e lo script bash ovviamente; ds4check.sh

#!/bin/bash
# DS4 Check Script

pidfile=/tmp/ds4drv.pid

# check if process is already running
for pid in $(pidof -x /home/user/scripts/ds4check.sh $pidfile); do
    if [ $pid != $$ ]; then
      echo "[$(date)] : ds4check.sh : Proccess is already running with PID $pid" >> /home/user/.cache/ds4drv.log
      exit 1
# if not running then run and apply config
      else  ( ds4drv --hidraw --config /home/user/.config/ds4drv.conf )

      exit 0
    fi
done

# remove PID file on exit... hopefully
trap "srm -rv -- '$pidfile'" EXIT >> /home/user/.cache/ds4drv.log

bash shell-script udev

— Rui F Ribeiro
fonte

Puoi pubblicare la regola udev?

— Joe,

@Joe Se avessi letto il mio post, vedresti che è già lì nel mio post principale.

Quell'uso di /tmpè un difetto di sicurezza locale (eliminazione arbitraria dei file contro l'utente che esegue lo script), migliore da usare /var/runo simile. In caso contrario, i file PID saranno una soluzione così semplice con casi limite e problemi, a seconda di come le cose vanno in pezzi.

— thrig

Sono preoccupato per 2 punti

File PID che non conosco, ma suggerirei di utilizzare pgrepcome soluzione alternativa.
ds4drvsembra un demone ma udevsupporta solo processi a esecuzione breve.

RUN {tipo}

...

Questo può essere utilizzato solo per attività di primo piano molto brevi. L'esecuzione di un processo di eventi per un lungo periodo di tempo potrebbe bloccare tutti gli altri eventi per questo o un dispositivo dipendente.

L'avvio di daemon o altri processi di lunga durata non è appropriato per udev; i processi biforcati, staccati o meno, verranno uccisi incondizionatamente al termine della gestione degli eventi.

Crea una copia di quello script:

#!/bin/bash
# DS4 Check Script

pgrep ds4drv || ds4drv --hidraw --config /home/user/.config/ds4drv.conf & disown

— user.dz
fonte

Sì, ds4drvè un demone che viene eseguito in background, ma il problema con il mio script corrente non è quello di lasciarlo collegare, /dev/js0ma invece di collegarsi a una nuova istanza /dev/js1. La mia udevregola dovrebbe essere la correzione per l'esecuzione, /dev/js0ma non lo sta facendo correttamente. Per il tuo piccolo frammento, non funziona come previsto, probabilmente a causa di quel doppio tubo, perché quando provo a eseguirlo, non lo fa una cosa.

@ user94959, AFAIK non è possibile correggerlo js0, il kernel farà un incremento per ogni connessione del dispositivo (anche lo stesso dispositivo è stato sostituito). La cosa migliore è / aggiungere una regola udev per creare un collegamento simbolico. Ho controllato la documentazione a monte, mi suggerisce di utilizzare il file di servizio che avvierà il demone all'avvio. Potrei chiedere quale inconveniente è usare questo metodo?

— user.dz

Penso che il problema sia /dev/js0il livello utente predefinito, ma poiché lo script mi sta costringendo a eseguirlo a livello di root, lo collega /dev/js1invece a quello che mi serve per eseguire lo script come utente normale anziché root. Il motivo per cui mi costringe a correre come root è perché il file di configurazione che ho non si applica affatto. Il demone si aspetta root, invece del normale utente. Supponiamo che ci sia una piccola cosa che potresti fare per farlo funzionare al normale livello utente, ma non ha funzionato per me.