Services systemd

Chinaski tourne comme des services systemd standard sur Linux. Comme ce sont des unités avec template, un seul jeu de fichiers fait tourner n'importe quel nombre de sites sur le même hôte. Cette page couvre les trois familles d'unités fournies : le CMS lui-même, la sauvegarde quotidienne, l'adaptateur optionnel d'assistant IA, et comment les utiliser au quotidien.

Le service principal : `chinaski@<instance>`

Chaque instance du CMS tourne sous sa propre unité systemd. Activez et démarrez-en une nouvelle avec son nom d'instance :

systemctl enable --now chinaski@1

(2, prod, staging, n'importe quoi d'alphanumérique, fonctionnent de la même manière.) Ce dont l'unité s'occupe :

Fait tourner le CMS en tant qu'utilisateur dédié chinaski sans login, depuis le répertoire de cette instance.
Définit les chemins de base de données et de sortie automatiquement à partir du nom d'instance ; vous n'avez normalement pas à les configurer.
Lit un fichier env par instance, /etc/chinaski<instance>/env, que vous créez avant de démarrer. Il doit contenir CHINASKI_SECRET et LISTEN_URL (écoutez sur la loopback, par ex. http://127.0.0.1:3001, quand un reverse proxy est devant le site ; les commentaires du fichier d'exemple expliquent pourquoi c'est important).
Redémarre en cas d'échec après un court délai, limité à cinq tentatives par minute pour qu'une config cassée ne boucle pas indéfiniment.
S'arrête proprement : l'arrêt attend jusqu'à cinq minutes que les requêtes en vol et un build en cours se terminent.
Tourne en boîte : système de fichiers en lecture seule sauf son propre répertoire, pas de nouveaux privilèges, /tmp privé, mémoire plafonnée à 1 Go, CPU à 200 %.

Chaque instance est la même unité avec un nom différent, et chacune a sa propre base de données, sa sortie, et son environnement ; voir Instances pour le modèle complet.

Événements et logs

Tout aboutit dans journald, étiqueté chinaski-<instance> :

systemctl status chinaski@<instance>

Si le service échoue à démarrer, le journal montre pourquoi ; l'installeur y pointe automatiquement quand un premier démarrage échoue.

La sauvegarde quotidienne : `chinaski-backup@`

Chaque instance reçoit une unité oneshot correspondante et un timer :

Le service prend un instantané de la base de données de l'instance et reflète ses médias : en tournant avec une vue en lecture seule du répertoire du site et un accès en écriture seulement au répertoire de sauvegarde.
Le timer se déclenche quotidiennement à 03:17 heure locale (minute délibérément inhabituelle pour que plusieurs instances sur un même hôte ne sauvegardent pas au même instant), avec un petit délai aléatoire, et rattrape si l'hôte était éteint au moment dû.
Vérifiez qu'il est enregistré avec systemctl list-timers chinaski-backup@<instance>.timer : après avoir modifié une planification, vérifiez, car systemd saute silencieusement sur une chaîne de calendrier mal orthographiée.
Conçu pour durer moins de 10 minutes ; même une base de 1 Go se termine en bien moins d'une minute sur un disque local.

L'adaptateur optionnel : `chinaski-mcp@`

Si vous utilisez des assistants IA contre l'API d'un site, cet adaptateur a sa propre unité par instance :

Ordonné après l'unité du CMS de la même instance (pour que le CMS existe d'abord).
Lit son URL d'API et sa clé d'API depuis /etc/chinaski<instance>/mcp-env (également verrouillé en permissions).
Enveloppe de ressources plus petite que le CMS (moitié de la mémoire et du CPU), avec le même durcissement sandbox et le redémarrage automatique.

Activez-en un avec systemctl enable --now chinaski-mcp@<instance> après que l'instance du CMS correspondante existe.

Commandes du quotidien

systemctl restart chinaski@<instance>    # after manual file changes (e.g. admin assets)
journalctl -u chinaski@<instance> -f     # follow the log
systemctl list-timers 'chinaski-backup@*'   # confirm every backup schedule

Les déploiements ne changent pas l'unité ; le script de déploiement gère le redémarrage après un build vérifié. Si vous adoptez plus tard le Manager, il pilote ces mêmes unités par nom (start/stop/restart), pour que les instances puissent passer sous son contrôle sans être réinstallées.

Garde-fous, en résumé

Redémarrage automatique en cas d'échec (avec un plafond de backoff contre les boucles de crash).
Arrêts propres : les requêtes et les builds se drainent avant que le processus ne se termine.
Plafonds mémoire/CPU par unité, resserrés pour qu'un builder en emballement ne puisse pas affamer l'hôte.
Un sandbox par instance : aucune instance ne peut lire ou écrire les fichiers d'une autre.
Journald capture tout : aucun démon de journalisation séparé à gérer.