Updates: meditating on the description of your Rust supervisor helped clarify my own approach.
- Go based supervisor daemon runs as a systemd service on the host. I configure it to know about my particular game server and expected utilization target. - The supervisor is responsible for reconciling my desired expectations (a count, or % of cpu/mem/etc so far) with spinning up game servers managed by systemd (since systemd doesn’t natively support this sort of dynamism + go code is super lean). - If I want more than one type of game server I imagine I could extend this technique to spinning up more than one supervisor but I’m keeping that in my back pocket for now. - I haven’t thought up a reason to, but my Go supervisor might want to read the logs of my game servers through journald.
For my purposes I’m not making a generic solution for unknown workloads like your Rust supervisor, which probably helps reduce complexity.
My workstation uses systemd so I can see my supervisor working easily. Real heckin’ neat.
nice, I really think you’ll go far with that approach on a single server.
My only advice, is capture stdout from the supervisor of the child process (gameserver) instead of putting an own dependency on journald: because everyone speaks stdout and you can later enrich your local metrics with it if its structured well, and forward it centrally.