Hot reload

vi /etc/craft-file-gate/users.toml          # the server sees the edit and reloads
kill -HUP $(pidof craft-file-gate)          # or: reload right away

[reload]
watch = "auto"            # auto | inotify | poll
poll_interval_secs = 5    # period of the periodic reread

What is watched

config.toml always; users_file, roles_file and the [admin.tls] pair when they are configured. The server watches the directory of each file: an atomic replacement (sed -i, mv) and the switch of the ..data link of a ConfigMap or Secret volume are seen. Events are grouped in 200 ms bursts, and a single task re-reads. SIGHUP triggers a reload, even without watching.

What a reload does

It re-reads every watched file, whichever one changed.

An authentication, or a REST request, reads the users in effect when it arrives. A re-read file is judged as at startup. A defined environment variable keeps the last word.

What a reload applies, key by key

The keys marked ⟳ in the reference; a key without the mark is read at startup. The [[users]], [[roles]] and [[backends]] entries are reloaded when they live in users_file or roles_file; written in config.toml, they are read at startup. The [admin.tls] paths need a restart; the content of the pair, however, is re-read at every reload.

inotify or periodic re-read

All the keys: Reference [reload].

Both keys are read at startup.

• A single inotify instance per process, shared with the ban files; poll fits where they are scarce (fs.inotify.max_user_instances, per UID and for the whole node).
• The periodic re-read compares date, size, inode, ctime, owner and mode; an interval without change writes nothing.
• When the kernel event queue overflows (fs.inotify.max_queued_events), every file is re-read. Repeated overflows mean that a neighbor is churning the configuration directory: move the configuration, or raise the limit.

What you will see