J’ai remarqué que le plugin plante quelques fois en raison d’exceptions qui ne sont pas gérer (uncaught, ou unhandled…). Quand cela arrive le plugin ne fonctionne plus mais reste actif du coup il ne redémarre pas de lui même. Si je relance le deamon à la main ça refonctionne. Mais ça n’est pas très pratique…
J’aimerais savoir si vous pensez qu’il existe une possibilité d’automatiser le redémarrage du deamon?
En première instance j’avais pensé à un script qui observe les logs ewejee_node et qui lance le script restart contenu dans le plugin. Mais je ne sais pas si c’est la meilleur des solutions.
Vous pouvez p-e activer le heartbeat dans la config du plug-in.
Ceci fera en sorte que le core redémarrera le démon du plug-in s’il n’y a plus de mises à jour sur les commandes des équipements après le délai configuré.
Évidemment si certaines commandes sont mises à jour même si le démon ne fonctionne plus alors le heartbeat sera inefficace.
Et je pense qu’il fonctionne au vue du contenu du script restart.sh(qui semble juste tuer le process node au vu du contenu du script). Mais dans le cas que je décris plus haut il semble que le deamon ne s’arrête pas après certaines exceptions.
Je ne sais pas ce qu’est le script dont vous parlez, cela ne fait pas partie du core.
Le heartbeat fait exactement la même chose qu’un restart manuel donc s’il fonctionne c’est comme si vous cliquiez manuellement sur « redémarrer ».
On peut voir l’info dans le log du plugin (pas celui du démon) et je pense qu’il y a un message dans le centre de message également de mémoire.
Donc pouvez-vous montrer le log du plugin ?
Avez-vous le message dans le centre de message ?
Si pas c’est que le heartbeat ne redémarre pas le démon car certaines commandes sont encore mises à jour et donc le core pense que tout va bien; à juste titre, il ne peut pas deviner qu’il y a un problème si cela fonctionne encore en partie.
Oui c’est un script à l’intérieur du répertoire du plugin, il ne fait pas partie du core.
Concernant les logs du plugins en cas d’exception j’ai par exemple:
(node:1190) UnhandledPromiseRejectionWarning: FetchError: request to https://us-api.coolkit.cc:8080/api/user/login failed, reason: getaddrinfo ENOTFOUND us-api.coolkit.cc
at ClientRequest.<anonymous> (/var/www/html/plugins/ewejee/core/js/node_modules/ewelink-api/node_modules/node-fetch/lib/index.js:1461:11)
at ClientRequest.emit (events.js:400:28)
at TLSSocket.socketErrorListener (_http_client.js:475:9)
at TLSSocket.emit (events.js:400:28)
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:82:21)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:1190) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:1190) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Je ne suis pas sur de voir dans le centre de message des logs en rapport avec cette exception.
Si pas c’est que le heartbeat ne redémarre pas le démon car certaines commandes sont encore mises à jour et donc le core pense que tout va bien; à juste titre, il ne peut pas deviner qu’il y a un problème si cela fonctionne encore en partie.
OK je pense que je comprends ce que vous voulez dire mais avec les éléments que j’ai actuellement je ne peux être plus précis. Je vais observer le problème pour l’instant et surveiller les journaux (plugins + core). Dès qu’il se représentera je récupérerais l’intégralité des infos, ça sera plus précis de cette manière.
