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.

Definitely. Also, when you're in non-systemd environments, runit or supervisord will happily manage your undaemons.

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.

How does that work with nginx or haproxy, which support zero-downtime restarts?

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.

> If I write a server app that listens for client connections, why not daemonize that?

Because writing a daemon is almost always more work than writing an application that runs in the foreground. And systemd is capable of taking applications that run in the foreground and running them as daemons instead.

Put another way - if something else is doing all of the hard work for you, why would you want to write a daemon yourself, except possibly as a learning exercise?

Stated more accurately, services running under a supervision suite yield their daemon instantiation to the underlying process manager, for which enforcing a consistent daemon control framework is its purpose.

So has been the case since IBM AIX in 1992.

> why not daemonize that

Double-fork-detach was arguably only ever a hack to get around the limitations of the traditional Unix paradigm (using inetd to handle incoming connections and invoking a standard program to hand the connection off to).