[gelöst] /dev/ttyACM0: Device or resource busy. Ca. 30 Sek später /dev/ttyACM0

[cb2sela]

Meine FHEM Installation war schon älter und ich habe heute bei gleicher Hardware - einem raspberry pi 2B - auf rasbperry pi os buster lite upgegradet.

Ich bin schön brav so vorgegangen:

Code Auswählen Erweitern


sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo systemctl mask serial-getty@ttyAMA0.service
=> reboot

cd /tmp/
wget http://fhem.de/fhem-6.0.deb
sudo dpkg -i fhem-6.0.deb
sudo apt-get -f install #das behebt alle dependency-probleme und installiert das Paket gleich mit

shutdown und dann die usb-devices wieder anschließen.

Restore:

Code Auswählen Erweitern

sudo service fhem stop
sudo tar -xvzf /tmp/FHEM-2020xxxx.tar.gz -C /opt/fhem/


Seither habe ich nach einem reboot solche Einträge im Log:

Code Auswählen Erweitern

fhem-2020-12.log:2020.12.03 09:08:15 3: Opening CUL_0 device /dev/ttyACM0
fhem-2020-12.log:2020.12.03 09:08:15 1: CUL_0: Can't open /dev/ttyACM0: Device or resource busy
fhem-2020-12.log:2020.12.03 09:08:15 2: Switched CUL_0 rfmode to HomeMatic
fhem-2020-12.log:2020.12.03 09:08:46 1: /dev/ttyACM0 reappeared (CUL_0)


Meine Homematic Devices funktionieren trotzdem, aber die Meldung stört mich und ich würde es gerne verstehen.

Ein normales shutdown restart von fhem ohne kompletten reboot sieht sauber aus:

Code Auswählen Erweitern

fhem-2020-12.log:2020.12.03 16:18:05 3: Opening CUL_0 device /dev/ttyACM0
fhem-2020-12.log:2020.12.03 16:18:05 3: Setting CUL_0 serial parameters to 9600,8,N,1
fhem-2020-12.log:2020.12.03 16:18:05 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
fhem-2020-12.log:2020.12.03 16:18:05 3: CUL_0 device opened


An meinem pi hängt ein Homematic-Cul und ein Jeelink-Stick:

Code Auswählen Erweitern

pi@raspi2wz:/opt/fhem/log $ ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Dez  3 16:24 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dez  3 16:24 usb-FTDI_FT232R_USB_UART_AL014KDX-if00-port0 -> ../../ttyUSB0
pi@raspi2wz:/opt/fhem/log $

Die /dev/tty-Devices sehen so aus:

crw-rw---- 1 root dialout 166,  0 Dez  3 16:57 /dev/ttyACM0
crw-rw---- 1 root dialout 204, 64 Dez  3 16:24 /dev/ttyAMA0
crw-rw---- 1 root dialout 188,  0 Dez  3 16:24 /dev/ttyUSB0



Ich habe bisher schon...
* Die Steckplätze meiner beiden USB-Devices getauscht und neu gebootet
* Geprüft, ob der user fhem in der Gruppe dialout ist (ja - fhem : dialout audio )
* Gem. https://forum.fhem.de/index.php?topic=64068.0 soll man in der /boot/cmdline.txt noch den console=serial0 Eintrag löschen.
   Erledigt aber geht immer noch nicht.
* Ein fhem update gemacht

Was läuft schief und wie werde ich die Meldung wieder los? Und zwar nicht durch loglevel runterschrauben... 

[KölnSolar]

guck mal mit dmesg in der Konsole, ob Du gleichzeitig etwas im System-Log siehst...
Da sollten connects/disconnects recht gut erkennbar sein und möglicherweise dann auch mit einem weiterführenden Hinweis.
Grüße Markus

[cb2sela]

Ich kann da nix erkennen, aber mir fehlt da auch das Know-How und der Blick.

Ich füge mal den fraglichen Abschnitt aus der fhem.log und den dmesg -T output bei.

[KölnSolar]

Ich kann da nix erkennen

Wo nix is, kann man auch nix sehen. 
Auf jeden Fall würd ich den usb Befehl mal aus der Konfiguration rausnehmen. Der frisst nur unnötig Zeit, da Du ja kein neues device hast.

Und dann könnt ich mir vorstellen, dass Dein FHEM zu früh startet. Das

Ein normales shutdown restart von fhem ohne kompletten reboot sieht sauber aus:

sagte das ja eigentlich schon aus.
Frag mich aber nicht, wie man den verzögerten Start bewerkstelligt. Da müssen andere ran oder Du suchst mal(das Thema gab es schon mehrfach)

Grüße Markus

[cb2sela]

Nun bin ich unsicher, ob es mehr als nur ein kosmetisches Problem ist. Als ich grade runterkam haben sowohl der Jeelink als auch der CUL geblinkt wie die Weihnachtsbäume.

Dass mein Jeelink trotz diverser Maßnahmen immer wieder mal blinkt kenne ich schon, aber mein CUL war bisher brav.

Ich bin mir jetzt unsicher: Ist es normal und war das vorher auch schon so, dass mein Busware CUL ca. im 1-sek-Takt grün blinkt?

Ich habe gem. https://wiki.fhem.de/wiki/CUL set CUL_0 raw l01  # (Blinkt bei Senden oder Empfangen von Paketen) gemacht und sogar rebootet aber dann bleibt die grüne LED dauerhaft aus und es blinkt auch z.B. beim Öffnen eines Fensterkontakts gar nichts mehr.

Wieso verhält er sich nun anders?

Den Tipp mit verzögertem Start habe ich weiter verfolgt und in meine /etc/systemd/system/fhem.service unter [Service] noch ein

Code Auswählen Erweitern

ExecStartPre=/bin/sleep 60

hinzugefügt und nochmal neugestartet.

Siehe da: Keine Fehler mehr im fhem.log! 

Code Auswählen Erweitern

2020.12.03 21:01:35 3: Opening CUL_0 device /dev/ttyACM0
2020.12.03 21:01:36 3: Setting CUL_0 serial parameters to 9600,8,N,1
2020.12.03 21:01:39 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2020.12.03 21:01:39 3: CUL_0 device opened
2020.12.03 21:01:39 2: Switched CUL_0 rfmode to HomeMatic


Dafür erstmal vielen Dank!!!

Trotzdem interessiert mich noch, was da schief läuft und warum ich nun unter Buster Ärger mit dem CUL habe und vorher nie.

Weitere Anregungen deswegen gerne willkommen.

[Wernieman]

Ich würde denken, das der Kernel die USB-Geräte noch "hochfährt", während fhem schon startet ...

Hinweis: "dmegs -T" ist nach meiner Erfahrung nicht so genau. Es können gerne Unterschiede von mehreren Sekunden auftauchen (Berufliche Erfahrungswerte, steht aber auch in der man-page). Und sowohl in FHEM also auch in dmesg steht zur gleichen Zeit usb-innitialisierung drin.

Deshalb auch Empfehlung (Siehe Empfehlung KölnSolar): Nimmt den "inital-usb" SCAN raus!

Code Auswählen Erweitern

attr initialUsbCheck disable 1

Wegen der "Kosmetik" kann ich dir nicht helfen ..

[cb2sela]

Danke für die Rückmeldungen. Ich setze das Thema auf gelöst, weil ich die Meldungen mit dem

Code Auswählen Erweitern

ExecStartPre=/bin/sleep 60
in der fhem.service wegbekommen habe. Ein

Code Auswählen Erweitern

attr initialUsbCheck disable 1
hat (allein) nichts gebracht, aber von den 60 verlorenen Sekunden durch das ExecStartPre hole ich nun immerhin ca. 8 Sekunden wieder rein 

[Otto123]

Falls Du von den 60 sec weg willst.
Es gab da mal das Problem mit dem hciuart Service. https://forum.fhem.de/index.php/topic,110716.0.html

Es gibt ja eventuell mehrere Dienste die im System starten und einfach alle Schnittstellen abklappern. Dabei könnte das zu solchen Konkurrenz Situationen kommen.

Also anstatt stumpfe Verzögerung eventuell noch mal Abhängigkeiten probieren?