Rechargement

vi /etc/craft-file-gate/users.toml          # le serveur voit l'edition et recharge
kill -HUP $(pidof craft-file-gate)          # ou : recharger tout de suite

[reload]
watch = "auto"            # auto | inotify | poll
poll_interval_secs = 5    # periode de la relecture periodique

Ce qui est surveille

config.toml toujours ; users_file, roles_file et la paire [admin.tls] quand ils sont configures. Le serveur surveille le repertoire de chaque fichier : un remplacement atomique (sed -i, mv) et la bascule du lien ..data d’un volume ConfigMap ou Secret sont vus. Les evenements sont regroupes par rafale de 200 ms, et une seule tache relit. SIGHUP declenche un rechargement, meme sans surveillance.

Ce qu’un rechargement fait

Il relit tous les fichiers surveilles, quel que soit celui qui a change.

Il applique	Il garde
les cles marquees ⟳ dans la reference	les sessions SFTP etablies, avec ce qu’elles ont resolu a leur authentification
`users_file` : utilisateurs, hashs, cles, `authorities`	un fichier refuse : rien n’en est applique
`roles_file` : roles, montages, ACL, backends, client `auth.authz_base_url`	les autres cles : une edition est nommee, jamais appliquee
la paire TLS admin, si ses octets ont change

Une authentification, ou une requete REST, lit les utilisateurs en vigueur a son arrivee. Un fichier relu est juge comme au demarrage. Une variable d’environnement definie garde le dernier mot.

Ce qu’un rechargement applique, cle par cle

Les cles marquees ⟳ dans la reference ; une cle sans marque est lue au demarrage. Les entrees [[users]], [[roles]] et [[backends]] sont rechargees quand elles vivent dans users_file ou roles_file ; ecrites dans config.toml, elles sont lues au demarrage. Les chemins de [admin.tls] demandent un redemarrage ; le contenu de la paire, lui, est relu a chaque rechargement.

inotify ou relecture periodique

Toutes les cles : Reference [reload].

Les deux cles sont lues au demarrage.

Une seule instance inotify par processus, partagee avec les fichiers de bans ; poll convient la ou elles sont rares (fs.inotify.max_user_instances, par UID et pour tout le noeud).
La relecture periodique compare date, taille, inode, ctime, proprietaire et mode ; un intervalle sans changement n’ecrit rien.
Quand la file d’evenements du noyau deborde (fs.inotify.max_queued_events), tous les fichiers sont relus ; des debordements repetes disent qu’un voisin agite le repertoire de configuration : deplacez-la, ou montez la limite.

Ce que vous verrez

Ligne `INFO`	Sens
`hot reload armed (file watch + SIGHUP)`, `... (periodic re-read + SIGHUP)`	le mode en vigueur ; champ `watching`
`file change detected, reloading configuration` (ou `... by the periodic re-read ...`, `SIGHUP received, ...`)	un rechargement commence
`hot-reloaded users file`, `hot-reloaded roles file`, `log level reloaded`, `audit trail filter reloaded`	ce qui est applique
`inline config — roles not hot-reloadable`	au demarrage : roles et backends dans `config.toml`