[djsumdog]

Have you looked at the runit init system? Here is /etc/sv/sshd/run on void linux:

    #!/bin/sh
    ssh-keygen -A >/dev/null 2>&1 # Will generate host keys if they don't already exist
    [ -r conf ] && . ./conf
    exec /usr/bin/sshd -D $OPTS

Service scripts are dead simple on Void.

[agumonkey]

Where do you specify laziness, failure policy etc ?

[hedora]

Why would I specify those in an init script? openssh has been doing The Right Thing(TM) for about two decades.

Also, openssh has protocol-specific (and secure by default) configuration options around connection lifecycle, etc. that no general purpose init system should try to replicate and then blindly apply to unrelated services.

[geofft]

OpenSSH is the unusual case. Most the the services I run don't do the right thing. That's why, for instance, Debian wrote the start-stop-daemon utility years before anyone ever dreamed of systemd.

I've been greatly enjoying systemd for the ability to write services and startup jobs in languages that don't have great libraries for doing all the right things, like Python and shell, because it gives me all those Right Things as effectively a library. I don't have to manage pid file handling and daemonization and restarts on my own; systemd will do it, and will do it well and Right. (I used to do this with start-stop-daemon, and it did it poorly and only okay.) It will also get out of the way of OpenSSH, which does it well and Right, and get in the way of the dozens of services that think they're doing it well and Right but aren't.

Easy things should be easy, and hard things should be possible. systemd supports both. If that's the extent of what runit can in fact do, it only supports the former. (SysV-style init, of course, just makes easy things hard and hard things confusing, but as everyone else is saying, it's very not the standard of comparison here.)