linger · XDG_RUNTIME_DIR · vérification du démon · triage par couches · région API et egress
Ingénieurs plateforme, SRE et opérateurs d'agents self-hostés échouent en 2026 sur VPS Linux moins sur une faute de frappe que sur systemd utilisateur arrêté après logout SSH, XDG_RUNTIME_DIR absent hors chemins interactifs, journaux gateway-canal-modèle lus comme un seul bloc, et décalage entre région API choisie en console et chemin d'egress réel du VPS. Ce texte liste cinq coûts cachés avant prod, un tableau à trois modèles bare-metal systemd contre systemd dans conteneur contre Docker seul, un runbook en six étapes avec commandes, une checkliste et trois faits techniques citables, plus une matrice de décision. Installation et gateway : checklist install et doctor. Compose : baseline production Docker Compose. Commande : page de commande.
OpenClaw sur Linux déplace processus longue durée, répertoires de sockets, journaux et sémantique de redémarrage depuis l'habitude personnelle vers des unités auditables. Les cinq points ci-dessous arrivent ensemble et mènent à un seul garde-fou : écrivez linger et XDG_RUNTIME_DIR sur la feuille d'acceptation avant la discussion Docker.
Liaison de session : sans linger, la fin d'une session SSH interactive peut arrêter le gestionnaire systemd utilisateur ; les unités meurent la nuit sans bruit.
Répertoire runtime manquant : cron, shells minimaux ou mauvais types de service laissent XDG_RUNTIME_DIR vide et éclatent les erreurs entre l'app et systemd.
Couches ignorées : écoute gateway, jetons canal, routage modèle et 429 amont fusionnent en « OpenClaw est cassé ».
Dérive région vs egress : la console pointe région A tandis que le chemin VPS renvoie des indices région B dans les en-têtes, ce qui ressemble à une auth intermittente plutôt qu'à un 403 stable.
Frontières mélangées : Docker plus unités utilisateur sur un même hôte désalignent ordre de redémarrage et sémantique health, ce qui brouille les rollbacks.
Comparez unités utilisateur hôte et PID 1 conteneur avec le tableau suivant comme diapositive de revue, pas comme slogan.
Décidez d'abord qui porte redémarrages, rotation des journaux, sémantique linger et frontière sockets contre ports hôte. Pas de solution universelle, seulement une frontière d'exploitation adaptée.
| Modèle | Usage typique | Bénéfice principal | Coût principal |
|---|---|---|---|
| systemd bare-metal (utilisateur) | VPS unique, travail serré avec pare-feu hôte et loopback | Aligné sur la distro, unités et journal cohérents | linger et bords de session login obligatoires |
| systemd dans conteneur | Supervision multi-process dans l'image | Proche d'un hôte de services Linux classique | Arêtes privilèges-image plus vives, debug intérieur et extérieur |
| Docker seul | Compose ou orchestrateur possède health et restart | Artefacts versionnés et rollbacks clairs | La sémantique linger utilisateur hôte n'est pas automatique |
L'acceptation reproductible n'est pas « ça tourne sur mon portable », c'est « l'unité survit à la fin SSH, le journal est lisible, les indices région sont capturés deux fois avec les mêmes commandes ».
Ordre : garder le gestionnaire utilisateur vivant sans supervision, valider le répertoire runtime, installer les unités, trier par couches, puis capturer des instantanés d'egress. Chaque étape livre des sorties de commande sauvegardées. La baseline gateway reste dans la checklist install et doctor.
Fixer l'utilisateur service : compte et groupe principal stables, pas de mélange root. Livrable : id et court extrait loginctl user-status.
Activer linger : pour l'utilisateur de déploiement, afin que user@ tourne sans login. Livrable : show-user affiche linger=yes.
Valider XDG_RUNTIME_DIR : imprimer depuis le même profil que l'unité, attendre une forme /run/user/<uid>.
Installer et activer : placer l'unité en scope utilisateur, daemon-reload et enable --now, vérifier Active et pid principal avec status.
Échantillonner par couche : d'abord écoute et parse config gateway, puis jetons canal et webhook, puis quotas amont et en-têtes région. Garder les deux cents dernières lignes journal par couche.
Cohérence egress : résoudre le même hôte et capturer métadonnées TLS visibles avant et après changement ; ne pas élever un RTT unique en conclusion de performance.
loginctl show-user "${USER}" -p Linger
sudo loginctl enable-linger "${USER}"
systemctl --user show-environment | grep XDG_RUNTIME_DIR || true
echo "${XDG_RUNTIME_DIR}"
systemctl --user daemon-reload
systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Note : remplacez openclaw-gateway.service par le vrai nom d'unité. Même autre binaire gateway, la ligne ExecStart de l'unité reste la référence.
Attribuez propriétaire et rythme de revue. Les contrôles région collectent uniquement des métadonnées TLS et réponse reproductibles, pas de classements de débit inventés.
Porte linger : chaque ticket doit joindre show-user Linger=yes en texte ou capture.
Frontière d'unité : documenter quels ports les unités utilisateur lient contre ceux publiés par conteneur, synchroniser la doc pare-feu.
Rétention logs : persistance journal ou relais distant décrits pour éviter disque plein par logs de debug.
Runbook par couche : au moins trois contrôles « passer à la suite » par couche gateway, canal, modèle.
Instantanés région : sortie résolveur et échantillons d'en-têtes avant et après fenêtre de release pour contraste rollback.
loginctl enable-linger agit sur la frontière de survie du gestionnaire systemd utilisateur ; ce n'est pas équivalent automatiquement au choix Docker./run/user/<uid>. Absente hors login, les sockets retombent sur des chemins non fiables.Attention : un curl réussi une fois ne prouve rien après bascule CDN. Nom d'hôte fixe et commandes répétables battent un tir chanceux.
Sans versions pour linger, noms d'unités, matrice de ports et instantanés région, la résidence Linux n'est qu'à moitié livrée. L'autre moitié partage le langage de responsabilité avec le triage gateway.
| Posture équipe | Défaut recommandé | Signal d'acceptation | Piège fréquent |
|---|---|---|---|
| Solo, itération rapide | Baseline Docker Compose | Health et restart reviewables dans compose | Ignorer mem_limit et rotation des journaux crée de faux blocages |
| Multi-locataire même machine | Frontière conteneur plus noms de projet isolés | Chaque pile a son répertoire de données | Mélange avec unités utilisateur crée des courses au redémarrage |
| Couplage serré hôte | systemd utilisateur plus linger | Le journal reste continu après fin SSH | XDG_RUNTIME_DIR non vérifié sur chemins non interactifs |
Bash interactif, nohup sans linger ou watchdogs artisanaux se paient souvent en revue de changement et audit. Sans instantanés egress, les pivots de politique région amont deviennent difficiles à expliquer. À l'inverse, capacité Mac cloud dédiée avec région choisissable et paliers réseau lisibles simplifie egress stable et images dorées avec builds iOS ou passation bureau.
Piège fréquent : croire que Docker efface toute sémantique systemd. Si des unités utilisateur hébergent encore la gateway hors Compose, linger et le répertoire runtime restent des portes dures.
Scripts personnels et exports d'environnement non versionnés survivent rarement à la passation et à la conformité avec un SLA externe. Quand OpenClaw doit partir avec politique région amont, empreinte TLS et narration d'egress fixe, les chemins bash-only manquent souvent de tickets de changement auditables. Pour les équipes qui regroupent passation iOS, régression CI et agents automatisés dans une seule acceptation et veulent commandes et paliers région plutôt qu'un pari egress maison, la location cloud Mac Mini VpsMesh est en général le meilleur alignement : nœuds dédiés simplifient ACL et noms d'hôte, la collaboration reste proche des boucles à fort churn, le langage d'exploitation peut suivre le runbook de nœuds de build réseau privé d'équipe. Mix régions sur la page tarifs, frontières de connexion selon le centre d'aide.
Après fin de session, systemd --user peut s'arrêter et emporter les unités OpenClaw utilisateur. Vérifiez linger avant prod et croisez connexion plus résidence dans le centre d'aide pour éviter de confondre arrêts nocturnes et pannes amont.
Fixez nom d'hôte et version d'outil, stockez résolution et métadonnées TLS visibles pour le même endpoint, comparez réglage région console et variables d'environnement. Santé au niveau Compose : article baseline production Docker Compose.
Quand redémarrage, rotation, limites et healthchecks sont entièrement dans Compose ou un orchestrateur et que vous n'avez pas besoin de sockets utilisateur hôte plus linger, Docker seul est souvent plus simple. Terminez l'acceptation par couches de la section trois avant de mélanger avec des unités utilisateur.