Run in the foreground and systemd will do the right thing.
Your app is still the one listening for connections, systemd just calls wait() until you exit, then launches you again.
There's no need for you to do a fork() or setsid() or whatever, that was a relic of the "just run all these init files as scripts" nature of sysv init.
I just started using runit and really like how simple it is. I feel like nows a good time to plug void linux http://www.voidlinux.eu/ which I think is pretty cool, it's the only OS/distro I know that uses runit as the init system.
That's a really interesting question, actually. (This was posted a day ago so I'm not sure anyone will read this any more, but...)
If the job of a process "supervisor" is to launch you, wait(2), launch you again, repeat... who has the role of doing zero-downtime restarts?
I'll define a zero-downtime restart in this instance as: a new process must be launched while the old process is still running, so it can negotiate a handoff of responsibility (via migrating who owns the port and draining connections in the case of nginx or haproxy), and the old process only dies once the handoff is complete.
If you wanted this behavior with systemd/upstart/etc as a supervisor (where processes are foregrounded and monitored), the supervisor would require a special case for "restart" which would just start a new process and monitor that one instead, and not bother with killing the old one.
I have no idea if systemd can accommodate for this without switching to a non-supervised process management mode (which is definitely possible.) I don't have much familiarity with advanced systemd or upstart, although I have plenty of familiarity with mesos schedulers, which can be kind of a datacenter-level version of systemd, and in this instance we do "rolling restarts" where new instances are launched, we wait for them to pass health checks, and then we drain the old ones, while a load balancer is responsible for routing incoming connections to the healthy instances. It's an interesting notion for what a single machine's process supervisor should do in this case.
If nginx and haproxy switch over to SO_REUSEPORT (and the SO_REUSEPORT semantics are fixed in Linux to work like FreeBSD's) it should no longer be an issue: its own worker supervisor need not fork itself, and it can simply manage the children.
Your app is still the one listening for connections, systemd just calls wait() until you exit, then launches you again.
There's no need for you to do a fork() or setsid() or whatever, that was a relic of the "just run all these init files as scripts" nature of sysv init.