When zackup runs as daemon, executing commands like zackup run (and in the future probably also zackup prune, #3) causes the global state to become stale. While the effect is mostly of cosmetic nature (timestamps and usage statistics in the UI), the metrics exported to Prometheus are just wrong.
There are two ways to mitigate this: Either nudge the server to reload the state, or pass the command to the server instance, execute it there and return the output to the CLI process.
In both cases, the server needs to maintain a form of IPC mechanism (the HTTP server is already present, but a Unix socket has less overhead).
- By exposing it via HTTP, a "reload" button in the UI could become feasible as well.
- Discovering whether a server runs in the background is easier with a Unix socket (it's a file in
/var/run), because the server's HTTP listen address could be anything (it is given at the command line, not defined in the config file).
- A third option is sending SIGHUP or similar to the server process to trigger a reload (though we'd need to know the server's PID).
When
zackupruns as daemon, executing commands likezackup run(and in the future probably alsozackup prune, #3) causes the globalstateto become stale. While the effect is mostly of cosmetic nature (timestamps and usage statistics in the UI), the metrics exported to Prometheus are just wrong.There are two ways to mitigate this: Either nudge the server to reload the state, or pass the command to the server instance, execute it there and return the output to the CLI process.
In both cases, the server needs to maintain a form of IPC mechanism (the HTTP server is already present, but a Unix socket has less overhead).
/var/run), because the server's HTTP listen address could be anything (it is given at the command line, not defined in the config file).