Proxmox LXC Container bei USB-Busänderung automatisch neu starten

[betateilchen]

Für Flightradar24 betreibe ich hier einen ADSB-Feeder in einem LXC-Container unter Proxmox.
Dazu habe ich ein USB-Passthrough für den verwendeten SDR-Stick eingerichtet

Code Auswählen Erweitern

dev0: /dev/bus/usb/001/010,mode=0666
So weit, so gut. Nun kommt es aber vor, dass sich durch Neustart oder Änderungen an den USB Geräten am Host die Bus-Zuordnung ändert und der SDR-Stick dann einfach nicht mehr verfügbar ist. Das ist nicht ohne weiteres erkennbar. Nachdem man die Zuordnung dann korrigiert und den Container dann neu gestartet hat, funktioniert alles wieder - bis zur nächsten Änderung.

Dazu habe ich mir jetzt ein Skript zur Überwachung und automatischen Korrektur gebaut:

Code Auswählen Erweitern

#!/bin/bash

USB=`lsusb |grep RTL2832U|awk '{print "dev0: /dev/bus/usb/" $2 "/" $4 ",mode=0666"}'|sed s/:,/,/`
DEV=`cat /etc/pve/lxc/110.conf |grep dev0`

if [ "$DEV" != "$USB" ];
then
 sed -i /dev0/d /etc/pve/lxc/110.conf
 echo $USB >>   /etc/pve/lxc/110.conf
 /usr/sbin/pct reboot 110
fi

#

Wird per cronjob regelmäßig aufgerufen und prüft, ob sich Container-config und USB-Bus-Liste unterscheiden. Wenn ja, wird die config angepasst und der Container neu gestartet.

Hat sich bisher gut bewährt, vielleicht kann es ja jemand gebrauchen. Das Prinzip läßt sich natürlich auch für andere USB Geräte verwenden

[Ralli]

Danke. Mit udev-rule war das nicht in den Griff zu bekommen?

(https://coldcorner.de/2018/07/12/proxmox-usb-passthrough-fuer-lxc-container-z-wave-uzb1/ plus Kommentare)

[betateilchen]

Hätte man vielleicht machen können.

Aber Proxmox hat halt seit 8.x die Einbindung von USB Geräten prinzipiell stark vereinfacht, indem man ein Gerät einfach als Ressource vom Host auf den Container mappen kann. In vielen Fällen funktioniert das auch problemlos und eindeutig, insbesondere bei Datenträgern und seriellen ports (z.B. zigbee). Dort kann man einfach beispielsweise /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_987dce184bbeed11b7ab642e38a92db5-if00-port0 als Ressource angeben und es ist egal, in welchem USB port der Stick steckt.

Bei dem SDR Stick ist es halt so, dass der von Haus aus nicht als Gerät unter "/dev/irgendwas..." auftaucht und es gibt die zusätzliche Herausforderung, dass die zugehörigen Kernelmodule nicht benutzt werden dürfen, wenn man ihn für das Szenario "FR24 feeder" einsetzen möchte.

Man muss eben mit dem Manko leben, dass man für den Stick den usb-port genau als Ressource angeben muss und dass sich die Nummerierung der ports zwischendurch mal ändern kann. Da fand ich das kurze Bash-Skript die schnellere Lösung, als sich mit udev rumschlagen zu müssen, was man ja mit dem ressourcen-Mapping genau umgehen wollte.

Das Skript automatisiert lediglich die beiden Schritte "ermitteln der Bus-Position" und "Mappen der Bus-Position in den Container", die man ansonsten von Hand machen würde.

[betateilchen]

Beim Basteln an dem Thema ist mir aufgefallen, dass pct <ctid> reboot einen container tatsächlich nur neustartet, wenn er schon läuft. Ein heruntergefahrener container wird aber so nicht gestartet, es kommt vielmehr zu einer Fehlermeldung "not running".

Mein Plan war eigentlich, das "start on boot" abzuschalten und mich darauf zu verlassen, dass der cronjob den container dann startet. Falsch gedacht...

Also müsste in das Skript auch noch eine Fallunterscheidung, ob der container gestartet oder neugestartet werden muss.

Dann kam ich zu einer anderen Lösung:

Inzwischen habe ich die Ermittlung der bus-Position für die betreffenden devices (es sind glücklicherweise nicht allzu viele) zusätzlich in die 'pre-start'-hookscripts der entsprechenden zwei Container eingebaut.

Damit wird schon beim Starten der Container die Konfiguration entsprechend korrigiert und das gewünschte device verwendet - egal, auf welchem Weg der Container gestartet wird.