Exploitation

#Service utilisateur systemd

Installez les unités de packaging/systemd/ sous ~/.config/systemd/user/, puis :

systemctl --user daemon-reload
systemctl --user enable --now automonique.socket automonique-tempfs-owner.service automonique.service
systemctl --user enable --now automonique-manage-worker.service
systemctl --user enable --now automonique-backup.timer
systemctl --user status automonique-tempfs-owner.service automonique.service

L’unité socket détient le listener d’administration privé à travers les redémarrages du daemon. Le service délègue son sous-arbre cgroup et attend la vraie notification de disponibilité du daemon. Un rechargement supervisé (SIGHUP) recharge approvals/approvals.conf sans changer de PID ; un remplacement refusé laisse la politique active intacte.

#Mises à jour et générations

Une mise à jour du daemon passe par une nouvelle génération, avec passation du travail en cours :

automonique reload sha256:<manifest-digest> --wait
automonique reload-status <reload-id>
automonique generations
automonique rollback --wait

Les releases qui ne changent que des compétences se rechargent à chaud, sans redémarrage du processus.

#État, métriques et journal

automonique status --json est la vue bornée de l’état durable, et automonique metrics renvoie les métriques au format texte Prometheus. Les deux passent par le socket d’administration local : il n’y a ni exporteur réseau ni traçage.

Le daemon écrit seulement des événements bornés et sans contenu dans le journal systemd : disponibilité, drainage à l’arrêt, panne de worker, stockage temporaire.

#Réconcilier un travail ambigu

Si un daemon précédent est mort après avoir pris un travail synthétique mais avant d’en enregistrer l’issue, son successeur reste en ligne à l’état failed, intake fermé. L’opérateur inspecte l’enregistrement durable et soumet une décision exacte, en échec uniquement :

automonique reconcile inspect <run-id>
automonique reconcile fail <run-id> <generation-id> <epoch> <revision> <decision-key>

La décision ne remet jamais en file un travail ambigu. Elle enregistre atomiquement l’échec et un reçu de réconciliation ; une répétition exacte rejoue le même reçu.

#Effets sortants ambigus

Les effets d’outbox expirés dont l’issue est ambiguë s’inspectent sans révéler leur contenu ni leur jeton de bail. Seul le reçu ou la raison est lu sur stdin, ce qui les garde hors des arguments et des listes de processus :

automonique outbox inspect <outbox-id>
printf '%s\n' '<receipt-or-reason>' | \
  automonique outbox reconcile <delivered|dead-letter> <outbox-id> <generation-id> \
  <epoch> <attempt> <revision>

#Sauvegarde et restauration

Le timer utilisateur crée un jeu de récupération en ligne toutes les cinq minutes. Le manifeste hache chaque membre et enregistre les résultats d’intégrité SQLite.

systemctl --user status automonique-backup.timer
automonique backup verify "$XDG_STATE_HOME/automonique/backups/recovery-..."
automonique backup create <backup-root>

Restaurez uniquement service arrêté, dans un répertoire d’état vide, depuis un binaire vérifié conservé hors du répertoire cible :

systemctl --user stop automonique.service automonique.socket
/path/to/verified/automonique restore --from <recovery-set> --into "$XDG_STATE_HOME/automonique"
# Installer la release vérifiée et activer son lien courant.
systemctl --user start automonique-recovery.service
automonique status --json

Un exercice de restauration local se lance avec automonique restore drill --scope local-fixture --from <recovery-set> --into <cible-vide>.

#Durabilité SQLite

Toutes les bases du runtime portent de l’autorité : aucune n’est traitée comme un cache jetable. Chaque connexion en écriture vérifie cette politique avant d’ouvrir son schéma, et refuse de s’ouvrir si une valeur ne correspond pas :