Je lèverai un ticket sur le github de la lib, mais week-end famille, pas d’avoir beaucoup de dispo
Mince, je viens de voir ton message!
Ca a crashé direct sans action de ta part? Tu es sur quel hardware exactement ?
Je fais tourner un Gladys sur Ubuntu server aussi, et je n’ai pas eu le problème. Il y a une erreur au démarrage mais qui ne fait pas crasher Gladys.
Il faudrait trouver un moyen de bétonner le code du core pour que ce genre de soucis n’affecte pas l’instance Gladys entière. J’ai déjà une todo en attente avant la RC qui est d’ajouter un listener sur le unHandledPromiseRejection error pour catcher les promises en erreur, mais ici j’ai plus l’impression que c’est un crash système impossible à catcher en node, je me trompe @AlexTrovato?
@pierre-gilles en effet j’ai l’impression qu’on est dans un cas non catchable. J’ai monté un ticket sur le github de noble pour savoir si on sait comment gérer ça.
Sinon je pensais faire un système dans Gladys, un paramètre qui dit si le démarrage du service s’est bien passé, sinon, au restart, “ignorer” le service, quitte à faire une page pour “forcer” le redémarrage du service. Et si ça plante à nouveau, recommencer ce process (changer le param de service pour dire que le chargement n’a pas réussi…).
Bonne idée ça ! ça nous éviterait bien des problèmes, parce que là potentiellement si un utilisateur novice avait le même bug que @VonOx, il aurait pas pu s’en sortir sans mettre les mains dans le cambouis (Watchtower ne met à jour que les containers qui tournent, pas ceux qui restart en permanence. En d’autres termes, si on fait crasher une version de Gladys, l’install de tout le monde est brické…).
Une autre option auquel je pensais (en complément de ton idée), c’est de faire tourner toute la partie services dans un worker node, on aurait donc un worker principal qui ferait la partie lib/API, et un worker secondaire pour les services. Après c’est un gros chantier donc c’est plus une idée « future »
Je ne suis pas contre un worker différent, mais à ce moment la, il faudrait voir même 1 worker par service.
En revanche, dans les 2 cas, c’est du boulot, mais je pense me pencher ASAP sur la première option, mais je ne suis pas capable de te donner un planning.
Si tu prends le sujet, préviens moi, qu’on se bosse pas en double, même si je pense que tu as bien d’autres tâches.
Aucune, watchtower a fait la mise à jour et crash
L’hôte n’a rien d’exotique, c’est un server Ubuntu 20.04 Xeon x64, pas de Bluetooth. J’ai que du docker dessus + Plex.
Je m’en suis rendu compte quand j’ai voulu géré mes hue car gladys plus m’affichait un dash vide ( d’ailleurs y’a un manque d’info si l’instance n’est pas up)
J’ai pas encore essayé de recréer le conteneur, je tente ça demain.
J’ai créé cette issue
J’ai essayé un conteneur tout frais ( nouvelle db ) , même crash
@AlexTrovato Mon idée du worker n’était pas pour répondre directement à ce problème, car dans ce cas là comme tu dis il faudrait un worker par service, ce qui n’est pas réaliste (l’usage RAM serait en augmentation constante en fonction du nombre de service utilisé).
L’idée du worker c’était juste de séparer le core des services afin que si la partie service reçoit trop d’events, bloque l’event loop, ou crash, au moins l’utilisateur a toujours accès à l’UI et peut gérer son instance Gladys.
Après, c’est un chantier plus long terme et il ne résout pas le problème ici. Je suis d’accord que ton idée 1 est bien.
Ok, tu vois ça comment niveau spec? Parce qu’au début je pensais faire quelque chose du style:
- Avoir en DB un attribut booléen dans la table « t_service », « has_crashed_last_boot »
- Au démarrage de chaque service, mettre le booléen à true en DB (comme ça si Gladys crash pendant le démarrage du service, et bien au prochain redémarrage Gladys verra le service à « has_crashed_last_boot » = true)
- Une fois que le service a démarré avec succès, mettre à jour le t_service avec has_crashed_last_boot = false.
Le problème, c’est que le crash n’intervient pas forcément au démarrage du service! Par exemple dans le cas de @VonOx, le crash est intervenu après:
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);
Du coup cette idée ne fonctionne pas… 
Tu pense à autre chose?
Ah en fait t’as déjà fais une PR ! Je viens de voir, désolé ^^
Je regarde ta PR !
Ok, j’ai fais des tests, au final cette solution est une bonne première solution @AlexTrovato ! C’est sur ça ne catchera pas tout, mais au moins pour les problèmes de style “incompatibilité hardware”, ça fait le boulot.
J’ai mis juste une remarque sur une migration que tu as supprimé, je ne suis pas sur qu’on veuille ça dans cette PR, mais sinon je suis d’accord pour merge.
Par contre, il faudra trouver un moyen de réactiver les intégrations dans l’UI, parce que là sinon elles sont “brickée” à vie.
Pour info j’ai tenter de lancer Gladys hors Docker, même erreur
Edit: Problème résolu avec un dongle branché
Sur l’hôte
sudo rfkill unblock all
sudo hciconfig hci0 up
Avec ça Gladys se lance ( y’ un truc qui va pas mais au moins ça tourne )
<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
Puis lors d'un scan....
<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
en cli sur l’hôte c’est ok
Problème résolu pour toi, mais ce n’est pas normal que ce crash soit arrivé. Cette issue reste une issue critique pour moi.
La solution de @AlexTrovato est bien pour prévenir des crash inattendu sur certains services nouveaux, mais ce bug reste là, brancher un dongle n’est pas une solution.
@AlexTrovato Tu sais ce qui pourrait résoudre ce bug ? C’est du côté de Noble à 100% ou c’est une issue qu’on pourrait résoudre de notre côté ? ( quitte à ne pas lancer le service bluetooth dans certains cas, la solution peut être de tout simplement désactiver le service bluetooth dans certains cas – sans restart de Gladys, car un reboot peut prendre plusieurs minutes sur un Pi, ce n’est pas une solution. )
Juste au niveau de la roadmap, j’ai fini toutes les tâches qui restaient avant la RC, et pour moi il me reste uniquement des todos documentation/site/marketing pour le lancement de la RC.
Donc toute cette semaine je vais travailler sur le site/la doc/contacter les bloggeurs, et ensuite dès que tout est prêt je lancerais Gladys v4.
La stabilité est du coup assez importante vu qu’on va avoir un afflux de nouveaux utilisateurs dans les prochaines semaines 
J’ai jamais dit le contraire , j’aurai dû écrire « j’ai résolu mon problème » . Les issues github reste ouverte
1 « J'aime »
Pour le souci, j’ai créé un ticket sur noble, je pense qu’en jouant avec de la config noble, on peut peut-être éviter le problème, mais le code est assez complexe et très spécifique à l’architecture hôte.
J’attends des réponses sur le github noble.
Je comprends !
Et tu sais si il y aurait moyen, hors Noble, de détecter la présence ou non de bluetooth sur l’hôte, et de désactiver le service si le Bluetooth n’est pas présent ?
@VonOx J’ai trouvé la PR “graal” pour nous sur le repo de watchtower, qui résoudra même les crashs les plus graves !
1 « J'aime »
Ah yes c’est tout frais en plus , je vais mettre un pouce en l’air pour que ça merge vite ^^
1 « J'aime »
J’ai fait 5 recherches de matériels bluetooth :
- le casque JBL apparaît autant de fois que j’ai fait de recherches, avec des adresses différentes :
bluetooth:5fcf91887a7e bluetooth:7592c20fbffa bluetooth:72274a02287e bluetooth:4534f2918e7b bluetooth:70d66dcd52a0 - mon robot tonseuse Automower apparaît avec son nom.
- 5 autres appareils sans nom.
Mon téléphone n’est pas détecté. Son adresse bluetooth n’est pas dans la liste, et inversement, il ne détecte pas Gladys.
Mon PC non plus.
Mon porte clé nut mini non plus
Beau travail !
Pour ma part les recherches bluetooth avec le nom :
[TV] Samsung Q80 Series (75)
Nut
J’ai 4 appareils détectés en plus mais je ne sais pas à quoi ils correspondent (surement téléphone, enceinte connectée …)
C’est quoi les cas d’utilisation du service déjà prévus ? A prévoir ?
Par ex, je n’ai pas l’impression que je peux tester la présence du porte clé nut