Watch
0
0
Fork
You've already forked hyperhive
0

swarm-nats: the auth responder has no start limit, always restarts, and is started after the server's restarts

This commit is contained in:
atlas 2026-11-12 06:00:53 +01:00 • committed by mara
commit 8530a5b7fd

View file

@ -80,10 +80,20 @@ On the queue's host, `swarm-bao-nats-callout-xkey` runs before the
The store has to be reachable each time the responder starts. When it's down,
the fetch unit fails and retries for a day. The server starts with the key
fetched last time, or not at all on a first boot. A responder that starts
while the store is down exits and retries every 5 seconds, and until one
start reads the seed the queue refuses every client, OIDC ones included. The
retry that lands the file starts or restarts the server, and the responder
comes up with it.
while the store is down exits and retries, first after 5 seconds and then
after longer waits up to a minute, and until one start reads the seed the
queue refuses every client, OIDC ones included. The retry that lands the file
starts or restarts the server, and the responder comes up with it.
The responder always comes back. Its unit has `Restart=always` and no start
limit, so a burst of starts can't leave it failed. A stop that comes from the
server failing isn't a restart trigger, so every host script that restarts
the server in `swarm-nats` (`swarm-bao-nats-tls` on a leaf rotation,
`swarm-bao-nats-callout-xkey` after fetching the keys) also clears the
responder's failed state and starts it. Those scripts use `start`, not
`restart`: the server's restart already restarts a running responder, which loads
the current seeds. Stopping the responder by hand lasts only until the next
key or leaf run, which starts it again. To keep it down, mask it.
The responder's store leaf is `deploy.nats.authBaoClientCertFile` /
`authBaoClientKeyFile`. On the store's host both default to the leaf