Ich werde ein Ticket auf dem GitHub der Bibliothek erstellen, aber am Wochenende ist Familie, also nicht viel Zeit.
Mist, ich habe gerade deine Nachricht gesehen!
Ist es direkt ohne deine Aktion abgestürzt? Auf welcher Hardware bist du genau?
Ich betreibe auch eine Gladys auf Ubuntu Server und hatte das Problem nicht. Es gibt einen Fehler beim Starten, aber er lässt Gladys nicht abstürzen.
Man müsste einen Weg finden, den Code des Kerns zu stabilisieren, damit solche Probleme die gesamte Gladys-Instanz nicht beeinflussen. Ich habe bereits eine To-do-Liste vor der RC, die darin besteht, einen Listener für den unHandledPromiseRejection-Fehler hinzuzufügen, um fehlerhafte Promises abzufangen, aber hier scheint es mir eher ein Systemabsturz zu sein, der in Node nicht abgefangen werden kann, liege ich falsch @AlexTrovato?
@pierre-gilles tatsächlich habe ich das Gefühl, dass wir in einem nicht abfangbaren Fall sind. Ich habe ein Ticket auf dem GitHub von Noble erstellt, um zu sehen, ob wir wissen, wie man damit umgeht.
Falls nicht, dachte ich daran, in Gladys ein System zu erstellen, einen Parameter, der angibt, ob der Start des Dienstes erfolgreich war, andernfalls beim Neustart den Dienst „ignorieren“, auch wenn eine Seite zum „Erzwingen“ des Neustarts des Dienstes erstellt werden muss. Und wenn es erneut abstürzt, diesen Prozess wiederholen (den Dienstparameter ändern, um anzugeben, dass das Laden nicht erfolgreich war…).
Gute Idee! Das würde uns viele Probleme ersparen, denn momentan könnte ein unerfahrener Benutzer, der denselben Fehler wie @VonOx hat, ohne „Schrauben“ nicht damit umgehen. (Watchtower aktualisiert nur die Container, die laufen, nicht die, die ständig neu starten. Mit anderen Worten, wenn eine Version von Gladys abstürzt, ist die Installation aller betroffen…).
Eine weitere Option, die mir einfiel (als Ergänzung zu deiner Idee), wäre, den gesamten Service-Teil in einem Worker-Node laufen zu lassen. Wir hätten also einen Haupt-Worker für die Lib/API und einen sekundären Worker für die Services. Allerdings ist das ein großes Projekt, also eher eine „Zukunftsidee“.
Ich bin nicht gegen einen anderen Worker, aber in dem Fall bräuchte man sogar einen Worker pro Service.
Andererseits ist in beiden Fällen Arbeit zu erledigen, aber ich werde mich so schnell wie möglich der ersten Option widmen, kann dir aber keinen Zeitplan geben.
Wenn du dich dem Thema widmest, lass es mich wissen, damit wir uns nicht doppelt Arbeit machen, auch wenn ich denke, dass du genug andere Aufgaben hast.
Nein, Watchtower hat das Update durchgeführt und es ist abgestürzt
Der Host ist nichts Exotisches, es ist ein Ubuntu 20.04 Xeon x64-Server, kein Bluetooth. Ich habe nur Docker und Plex darauf.
Ich habe es bemerkt, als ich meine Hue-Lampen verwalten wollte, da Gladys mir keine Dashboard mehr anzeigte (übrigens fehlt eine Info, wenn die Instanz nicht läuft).
Ich habe noch nicht versucht, den Container neu zu erstellen, ich versuche es morgen.
Ich habe dieses Issue erstellt
Ich habe einen ganz frischen Container (neue Datenbank) ausprobiert, aber es gab trotzdem einen Absturz.
@AlexTrovato Meine Idee für den Worker war nicht, um direkt auf dieses Problem zu reagieren, denn in diesem Fall, wie du sagst, bräuchte man einen Worker pro Dienst, was nicht realistisch ist (der RAM-Verbrauch würde in Abhängigkeit von der Anzahl der verwendeten Dienste ständig steigen).
Die Idee des Workers war einfach, den Kern der Dienste zu trennen, damit, wenn der Dienstteil zu viele Events erhält, die Event-Schleife blockiert oder abstürzt, der Benutzer zumindest immer Zugriff auf die UI hat und seine Gladys-Instanz verwalten kann.
Danach ist es ein langfristiges Projekt und es löst das Problem hier nicht. Ich bin einverstanden, dass deine Idee 1 gut ist.
Ok, wie siehst du das in Bezug auf die Spezifikationen? Denn anfangs dachte ich an etwas in der Art:
- In der Datenbank eine boolesche Eigenschaft in der Tabelle « t_service », « has_crashed_last_boot » haben
- Beim Starten jedes Dienstes den booleschen Wert in der Datenbank auf true setzen (damit, wenn Gladys während des Startens des Dienstes abstürzt, Gladys beim nächsten Neustart den Dienst auf « has_crashed_last_boot » = true sieht)
- Sobald der Dienst erfolgreich gestartet wurde, die Tabelle « t_service » mit has_crashed_last_boot = false aktualisieren.
Das Problem ist, dass der Absturz nicht unbedingt beim Starten des Dienstes auftritt! Zum Beispiel im Fall von @VonOx trat der Absturz danach auf:
2020-10-16T22:22:24+0200 <info> index.js:13 (Object.start) Starting usb service
2020-10-16T22:22:24+0200 <info> index.js:16 (Object.start) Starting zwave service
2020-10-16T22:22:24+0200 <info> index.js:15 (Object.start) Starting Bluetooth service
2020-10-16T22:22:24+0200 <info> index.js:19 (Object.start) Starting telegram service
2020-10-16T22:22:24+0200 <info> index.js:20 (Object.start) Starting Open Weather service
/src/server/services/bluetooth/node_modules/@abandonware/noble/lib/hci-socket/hci.js:100
this._deviceId = this._socket.bindRaw(deviceId);
Deshalb funktioniert diese Idee nicht.. 
Hast du eine andere Idee?
Oh, du hast schon ein PR gemacht! Ich habe es gerade gesehen, entschuldige ^^
Ich schaue mir dein PR an!
Okay, ich habe Tests durchgeführt, und am Ende ist diese Lösung eine gute erste Lösung @AlexTrovato! Klar, sie fängt nicht alles ab, aber zumindest bei Problemen wie „Hardware-Inkompatibilität“ erledigt sie ihren Job.
Ich habe nur einen Kommentar zu einer Migration hinterlassen, die du entfernt hast. Ich bin mir nicht sicher, ob wir das in diesem PR wollen, aber ansonsten bin ich damit einverstanden, zu mergen.
Allerdings müssen wir einen Weg finden, die Integrationen in der UI wieder zu aktivieren, denn sonst sind sie für immer „brickiert“.
Zur Info, ich habe versucht, Gladys außerhalb von Docker zu starten, gleiche Fehlermeldung
Bearbeitung: Problem mit einem angeschlossenen Dongle gelöst
Auf dem Host
sudo rfkill unblock all
sudo hciconfig hci0 up
Damit startet Gladys (da ist etwas nicht in Ordnung, aber zumindest läuft es)
<info> index.js:20 (Object.start) Starting Open Weather service
<info> index.js:16 (Object.start) Starting zwave service
<info> index.js:15 (Object.start) Starting Bluetooth service
<info> index.js:13 (Object.start) Starting usb service
<info> index.js:19 (Object.start) Starting telegram service
<error> bluetooth.connectDevices.js:37 () Could not start scanning, state is unknown (not poweredOn)
<error> bluetooth.connectDevices.js:37 () Could not start scanning, state is unknown (not poweredOn)
<error> bluetooth.connectDevices.js:37 () Could not start scanning, state is unknown (not poweredOn)
<info> connect.js:38 (MqttClient.<anonymous>) Connected to MQTT server mqtt://127.0.0.1:1883
<info> subscribe.js:12 (MqttHandler.subscribe) Subscribing to MQTT topic stat/+/+
<info> subscribe.js:12 (MqttHandler.subscribe) Subscribing to MQTT topic tele/+/+
<info> subscribe.js:12 (MqttHandler.subscribe) Subscribing to MQTT topic gladys/master/#
<info> index.js:63 (Server.<anonymous>) Server listening on port 80
Dann während eines Scans....
<error> bluetooth.connectDevices.js:37 () Bluetooth: peripheral node_id not found
<error> bluetooth.connectDevices.js:37 () Bluetooth: peripheral 001788286ece not found
<error> bluetooth.connectDevices.js:37 () Bluetooth: peripheral bridge not found
<error> bluetooth.connectDevices.js:37 () Bluetooth: Peripheral undefined not connectable
<error> bluetooth.connectDevices.js:37 () Bluetooth: peripheral 001788286ece not found
in der CLI auf dem Host ist alles in Ordnung
Problem gelöst für dich, aber es ist nicht normal, dass dieser Absturz passiert ist. Dieses Problem bleibt für mich ein kritisches Problem.
Die Lösung von @AlexTrovato ist gut, um unerwartete Abstürze bei einigen neuen Diensten zu verhindern, aber dieses Bug bleibt bestehen, ein Dongle anzuschließen ist keine Lösung.
@AlexTrovato Weißt du, was diesen Bug beheben könnte? Liegt es zu 100% bei Noble oder ist es ein Problem, das wir auf unserer Seite lösen könnten? (notfalls, indem man den Bluetooth-Dienst in manchen Fällen nicht startet, könnte die Lösung sein, den Bluetooth-Dienst in manchen Fällen einfach zu deaktivieren – ohne Neustart von Gladys, denn ein Reboot kann auf einem Pi mehrere Minuten dauern, das ist keine Lösung.)
Nur im Hinblick auf die Roadmap habe ich alle verbleibenden Aufgaben vor der RC erledigt, und für mich bleiben nur noch Dokumentations-/Website-/Marketing-Todos für den Start der RC.
Daher werde ich diese ganze Woche an der Website, der Dokumentation und dem Kontaktieren von Bloggern arbeiten, und sobald alles bereit ist, werde ich Gladys v4 starten.
Die Stabilität ist daher ziemlich wichtig, da wir in den nächsten Wochen einen Zustrom neuer Benutzer haben werden 
Ich habe nie das Gegenteil gesagt , ich hätte schreiben sollen « ich habe mein Problem gelöst ». Die GitHub-Issues bleiben offen
Für das Problem habe ich ein Ticket auf noble erstellt. Ich denke, dass man durch das Ändern der noble-Konfiguration das Problem möglicherweise umgehen kann, aber der Code ist recht komplex und sehr spezifisch für die Host-Architektur.
Ich warte auf Antworten auf dem noble-GitHub.
Ich verstehe!
Und weißt du, ob es eine Möglichkeit gibt, außerhalb von Noble zu erkennen, ob Bluetooth auf dem Host vorhanden ist oder nicht, und den Dienst zu deaktivieren, wenn kein Bluetooth vorhanden ist?
@VonOx Ich habe den „graal“-PR für uns im Watchtower-Repo gefunden, der sogar die schwerwiegendsten Abstürze behebt!
Ah ja, das ist alles ganz frisch. Ich werde einen Daumen hoch geben, damit es schnell gemerged wird ^^
Ich habe 5 Bluetooth-Geräte-Suchen durchgeführt:
- der JBL-Kopfhörer erscheint so oft wie ich gesucht habe, mit unterschiedlichen Adressen:
bluetooth:5fcf91887a7e bluetooth:7592c20fbffa bluetooth:72274a02287e bluetooth:4534f2918e7b bluetooth:70d66dcd52a0 - mein Automower-Rasierroboter erscheint mit seinem Namen.
- 5 weitere Geräte ohne Namen.
Mein Telefon wird nicht erkannt. Seine Bluetooth-Adresse ist nicht in der Liste, und umgekehrt erkennt es Gladys nicht.
Mein PC auch nicht.
Mein Nut Mini Schlüsselbund auch nicht.
Gute Arbeit!
Meine Bluetooth-Suche mit dem Namen:
[TV] Samsung Q80 Series (75)
Nut
Ich habe vier weitere Geräte erkannt, aber ich weiß nicht, was sie sind (wahrscheinlich Telefon, Smart Speaker …)
Welche Anwendungsfälle sind für den Dienst bereits vorgesehen? Welche sind noch zu berücksichtigen?
Zum Beispiel habe ich den Eindruck, dass ich nicht testen kann, ob der Nut-Schlüsselanhänger anwesend ist.