> I'm not sure why systemD is needed for restarting a process what about a simple loop with an if statement?
It's not needed, but that's why a lot of older apps have their very custom solution to deal with that issue. (For example MySQL) Each with their custom exit condition handling, cleanup, backoff, etc. A simple loop also won't cleanup processes forked from the main server.
if you go down the Restart=always route, please take a long look at StartLimitIntervalSec, RestartSec, StartLimitBurst. in some failure modes always isn't quite always always.
That's the whole point, you're not mysql. You don't need the sophistication of that magnitude. You need to run a standalone go binary to listen on a port. Simple. Why bother with the blackbox of systemD when you can perfectly get away with a basic shell script?
The first link you sent is 1024 lines long, do you genuinely believe using something like this is preferred to a simple shell script + nohup? I'm amazed at the hoops some devs jump through just to get to work with their favorite tool.
That script is never going to be simple in a few years. You're going to keep adding features to it with time until it badly implementsa tiny fraction of what you already had available in your init system. The question could be: why spend time rewriting a broken restart script if you already have a good version available behind a config switch.
If you don't like how long that man page is, you should check the size of bash+nohub man page which you'd otherwise need :-)
It's not needed, but that's why a lot of older apps have their very custom solution to deal with that issue. (For example MySQL) Each with their custom exit condition handling, cleanup, backoff, etc. A simple loop also won't cleanup processes forked from the main server.
This 1kLoC script https://github.com/mysql/mysql-server/blob/8.0/scripts/mysql... can be almost entirely replaced with a few lines of systemd.service config. (with fairly logical names for each setting)
Now we can replace those with "Restart=always". If you want to be fancy, you could even add a watchdog.
> Process isolation to run a go binary on a presumably dedicated web server?
1. "presumably" 2. Apparently a web server which gets SSH sessions from devs - nice place to check for forwarded keys or collect passwords.
> Privileged sockets, not even sure what those might be.
Ports below 1024 (or whatever your local threshold is)
> but what I hear is even more complicated
It really isn't. Just unfamiliar to you.