mirror of
https://github.com/R0m1k3/Loki.git
synced 2026-10-19 21:18:20 +02:00
En conteneur, start/stop/restart/status du moteur passent par `loki-rs engine <action>`, port à l'identique de la supervision Go : `loki serve` lancé chef de session, fichier PID et journal aux mêmes chemins (serviceIsActive, l'UI et `loki logs` lisent les mêmes fichiers), contrôle à 2 s avec la fin du journal en cas d'échec, arrêt de tout l'arbre — session, groupe et filiation, pour le moteur de Strata qui prend sa propre session — avec les mêmes délais (SIGTERM, 4 s, SIGKILL, 20 s). Le Go garde ses garde-fous (optimisation en cours, preset externe) puis délègue au loki-rs voisin de son binaire ; la dernière ligne d'erreur du superviseur devient l'erreur montrée par l'UI. LOKI_ENGINE_SUPERVISOR=go revient à l'ancienne supervision. `loki serve`, qui construit la ligne de commande du moteur, ne change pas : il aura son propre lot. Le contrôle « démarré ? » regarde si l'enfant est sorti plutôt que le signal 0 : un enfant mort reste un zombie tant que son parent vit, et un zombie répond encore au signal 0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.4 KiB
2.4 KiB
Migration Rust — lot 3 : supervision du moteur
Date : 2026-10-14 · Statut : livré · Prérequis : lots 1-2.
Découpage
Le « moteur » en conteneur, c'est deux couches de taille très différente :
- La supervision du processus (~350 lignes Go :
sys_service_container.go,sys_proctree_linux.go) — lancerloki servedétaché, fichier PID, journal, arrêter tout l'arbre (Strata compris) et attendre que la VRAM soit rendue. - La ligne de commande de llama-server / Strata (~9 000 lignes :
backend_serve*.go, presets, MoE, spéculatif, threads, cache…), là où s'applique la règle « ne jamais dénaturer les modèles ».
Le lot 3 porte la couche 1. La couche 2 reste au Go (loki serve) et fera
l'objet d'un lot dédié, parce que chaque option y a été réglée contre un
défaut mesuré.
Ce qui change
loki-rs engine start|stop|restart|status: port à l'identique de la supervision Go — chef de session (setsid), fichier PID et journal aux mêmes chemins ($LOKI_HOME/<service>.pid|.log), contrôle à 2 s avec les 20 dernières lignes du journal en cas d'échec, arrêt de l'arbre (session, groupe, filiation ; SIGTERM, 4 s, SIGKILL, 20 s au plus), mêmes messages.- Le Go garde ses garde-fous (optimisation en cours via
serviceAction, preset externe) puis délègue auloki-rsvoisin de son binaire.loki logs,enable/disablerestent au Go. - Porte de sortie :
LOKI_ENGINE_SUPERVISOR=go, ou absence deloki-rs. - Différence assumée : le contrôle « démarré ? » regarde si l'enfant est
sorti (
try_wait), pas le signal 0 — un enfant mort reste un zombie, qui répond encore au signal 0. - L'arrêt exclut de l'arbre
loki-rslui-même ET son parent (le Go qui l'a appelé), comme le Go excluait son propre PID.
Tests
- Rust (toutes plateformes) :
/proc/<pid>/statavec parenthèses dans le nom, arbre par session/groupe/filiation avec exclusion de l'appelant. - Rust (Linux, CI) : faux
loki servequi lance un enfant dans sa session et un « moteur » dans SA PROPRE session (comme Strata) — démarrage, « déjà démarré », arrêt de tout l'arbre, redémarrage, échec avec journal, PID nettoyé. - Go (Linux, CI) : choix du
loki-rsvoisin (absent, non exécutable,LOKI_ENGINE_SUPERVISOR=go), appel réel avec l'environnement attendu, erreur rendue = dernière ligne d'erreur du superviseur.