morfMonitor - v0.19.1

morfMonitor 0.19.1

• Styled the "Relancer le service" button. The initial restart button had no CSS class rule and rendered as unstyled black-on-white text; it now shares the .btn-update-service styling (and the confirm/retry variants match their update twins), so the restart control looks like the rest of the Services table.

morfMonitor - v0.19.0

morfMonitor 0.19.0

• Manual "Relancer le service" (restart) button for stuck services. When a service is flagged stuck (0.18.0), its Détail cell in the "Services morfSystem" tab now offers a restart action. morfMonitor stays an observer: it does not run systemctl - it relays a request over loopback to the local morfUpdate agent (POST /api/restart → 127.0.0.1:8794/api/v1/restart), exactly like the update button. The client sends only the declared project key (morfUpdate.targets); the real systemd unit is resolved and executed by the privileged agent, against its whitelist. No auto-restart: detection only makes the button available, the human decides. Progressive, popup-free feedback (Redémarrage demandé → en cours → Vérification → service relancé, with explicit failure + Réessayer), followed through the shared operation journal. A stuck service without a declared morfUpdate target shows "non relançable" rather than a dead button. Requires morfUpdate 0.5.0 on the same host.

morfMonitor - v0.18.0

morfMonitor 0.18.0

• "Stuck" detection: a live process that stopped answering. The per-service state in the "Services morfSystem" tab now crosses two signals morfMonitor already holds - systemd ActiveState (proof of life) and the freshness of the service's own morfBeacon heartbeat (proof of health). A service systemd still reports active while its heartbeat has gone silent for more than beacon.offline_after_s is alive but blocked ("muet"): the SIGSTOP / deadlock / busy-loop case that ActiveState cannot see, and that the TCP probe also misses (the kernel completes the connection without the application). Such a service is now flagged stuck in /status (with heartbeat_age_s / heartbeat_online) and shown as bloqué (red) instead of actif. Pure composition of observations already in hand - no new probe, no dependency, no privilege - and OS-agnostic, since it rides on the beacon rather than on systemd. Only services actually heard beaconing are judged: an app absent from the heartbeat table emits no beacon, so its silence proves nothing. The local host's instance is preferred (even when stale) so a healthy same-named service on another machine cannot mask a local freeze. Observation only - morfMonitor reports it, it does not act.

morfMonitor - v0.17.0

morfMonitor 0.17.0

• Functional-failure alerts pushed to morfNotify. morfMonitor now periodically (every 30 s, in-memory, never blocking) evaluates the parc health it already computes and, when a declared service stops announcing itself while its host is still online - i.e. hung or stopped, the case a live process hides from systemd - pushes an error notification to morfNotify (POST /notify), plus a recovery notice when it returns. This is the "functional failure" path (process up, silent), complementary to the systemd OnFailure bridge's "hard failure" path (process dead, see morfNotify 0.5.0). Sustained-failure debounce (120 s, so a restart or update does not alert) and a 6 h repeat cooldown keep it quiet. A whole machine going offline is not alerted service-by-service (that is a machine event, not a service fault). Targets come from MORF_ALERT_TARGETS or /etc/morfsystem/alert-targets (shared with the systemd bridge), defaulting to telegram; the morfNotify URL from MORFNOTIFY_URL. With both paths, morfDashboard is no longer a required link in the alert chain - it stays the visualisation.

morfMonitor - v0.16.2

morfMonitor 0.16.2

• Intermittent crash (SIGSEGV) that made the web UI show "Injoignable" and wipe every service. The morfUpdate version was read with a synchronous HTTP GET spinning a nested QEventLoop (loop.exec()), and that read was invoked from inside servicesJson() while it iterated m_beaconSeen. The nested loop re-entered the event loop, let an incoming beacon datagram run m_beaconSeen.insert(), and inserting a new key rehashed the hash table, invalidating the iterator of the in-progress walk -> segfault. This is why the service crashed in bursts right after start (every announcing service adds a new key) and then went quiet (known keys: insert only replaces a value, no rehash). systemd restarted it each time, and the ~6 s restart window is the "Injoignable" the UI displayed. Reproduced on both the 1 GB pi4dev and the 4 GB pi4fred, confirming it was not memory pressure.
• The morfUpdate version probe is now fully asynchronous (background request, 15 s cache, immediate /opt/morfupdate/VERSION fallback): no nested event loop, so no re-entrancy. This also removes the QIODevice::read: device not open warnings, which came from reading the reply aborted by the old 800 ms timeout.
• Defense in depth: servicesJson() now iterates a snapshot of the beacon keys (m_beaconSeen.keys()) instead of live hash iterators, so any future re-entrancy or side effect that mutates the table can no longer corrupt the walk. The two remaining synchronous QEventLoop GETs in HttpServer are on user-triggered update actions only; they no longer endanger this iteration.

morfMonitor - v0.16.1

morfMonitor 0.16.1

• Re-vendored morfDeploy 0.20.5 (opt-in arm64 cross-packaging and the sysroot .shlibs Depends resolution). The VERSION is bumped so the source tag matches the rebuilt artifact after this vendored-tooling update; without it the release provenance check rejects a package built past the previous tag.

morfMonitor - v0.16.0

morfMonitor 0.16.0

• Mise à jour d'un service : plus aucun popup. La confirmation, l'avancement et le résultat s'affichent désormais en ligne, dans la cellule « Mise à jour » du service concerné. Cliquer « Mettre à jour » pose la question sur place (« Passer à X.Y.Z ? » avec « Confirmer » / « Annuler ») au lieu d'ouvrir une boîte de dialogue.
• Avancement matérialisé. Pendant l'opération, une barre indéterminée défile sous le service, accompagnée de l'étape courante et de son rang (« Vérification (2/5)… ») en suivant les états de l'agent morfUpdate (téléchargement, vérification, installation, redémarrage, contrôle de santé). Le succès reste affiché quelques secondes puis s'efface ; un échec reste visible jusqu'à « Masquer », avec un bouton « Réessayer ».
• Message d'échec explicite pour une demande lancée trop tôt. Si la mise à jour est demandée pendant la publication de la release (le .deb est déjà en ligne, donc le bouton apparaît, mais manifest.json n'est pas encore attaché), l'agent échouait sur « release has no manifest.json » sans que la cause soit lisible. Ce cas est maintenant reconnu et affiché en clair : release incomplète, attendre une minute, « Vérifier les versions », puis relancer.

morfMonitor - v0.15.0

morfMonitor 0.15.0

• Section « Activités en cours » (page État) : affiche en temps réel ce que chaque service du parc est en train de faire (indexation, compilation, collecte, synchronisation...), de façon générique, selon le contrat activity/1 (morfSystem/docs/CONTRAT-ACTIVITE.md). Une ligne par service en ligne déclarant une activité : service, type, progression, durée, détail. « Aucune activité en cours » sinon. morfMonitor observe, il n'agit jamais dessus.
• Re-sondage périodique du /status des services en ligne (toutes les ~5 s, seulement quand un client regarde) pour capter le champ volatile activity.
• État matériel incohérent à distance. L'état matériel d'un service (bloc hardware de /status) n'était lu qu'une seule fois par version, comme un détail statique. Or il est volatile (un capteur s'initialise après le boot, se branche/débranche, se dégrade). Un morfMonitor distant ayant sondé morfSensor pendant son démarrage figeait « capteur absent » alors que le morfMonitor local, sondé plus tard, voyait « présent ». L'état matériel est désormais rafraîchi au fil du re-sondage périodique, il suit donc le service dans le temps.

morfMonitor - v0.14.11

morfMonitor 0.14.11

• morfsystem.json déclarait morfUpdate dans beacon_apps, alors que morfUpdate n'émet pas de heartbeat morfbeacon (il est supervisé en local via systemd_services + lecture /status). La vue Écosystème le marquait donc éternellement « introuvable » alors que l'onglet Services le montrait actif. morfUpdate retiré de beacon_apps (conservé dans systemd_services), dans le fichier déployé et l'exemple, avec une note expliquant pourquoi ne pas l'y remettre.

morfMonitor - v0.14.8

morfMonitor 0.14.8

• Suivi d'une mise à jour : si fetch tombe (dpkg arrête morfMonitor), l'UI retente ~3 min au lieu d'un pop-up « Failed to fetch » et d'abandonner.