Systemd integration

Proposal

It'd be nice to natively integrate into systemd (possibly as an optional feature). Interesting features:

• socket activation - get the listen sockets from systemd env var to enable parallel start
• notification - notify systemd when exactly the service started
• logging to journald - I'm not sure what the exact benefits are. Maybe nice, unified interface?

Analysis of available crates

I did preliminary research on available systemd crates:

• systemd (0.4.0) - binds to native library, doesn't support named fds
• libsystemd (0.2.1) - pure Rust lib, supports named fds, may contain unneeded stuff
• sd_notify (0.1.1) - looks minimalistic, which is nice but doesn't support named fds

I personally believe that named file descriptors are much more robust way of interacting with systemd and thus I'd recommend libsystemd even at the cost of having a larger library. Alternatively, we could try to add named fds to sd_notify or implement our own.

Considerations on interaction with configuration

There are various ways to handle the situation where configuration is supplied in the files and fds are available from systemd:

• Fail on confusing situation
• Warn, continue with systemd
• Warn, continue with configuration
• Fail unless a special switch explicitly defines the behavior (but what's that good for?)

I intuitively like warn, continue with systemd, can't explain why.

Another thing to consider is how the code should be structured. Currently we use Option and turn it into SocketAddr. We could turn it into a socket directly, but then we would have to bind inside configuration, which feels a bit weird. Alternatively we could create a new enum that can contain the file descriptor or address and then handle it in RPC acceptor. This solution feels quite clean, but maybe needlessly complex?

I was also thinking about combining this with configure_me somehow. Sure, it feels quite kitchen-sink-ey but it could have the ability to generate systemd socket files from specification. That'd be pretty cool. Maybe do it as a special library that can interact with configure_me in a reasonable way? Or finally implement interface file specification and do it there - that sounds quite nice, if done properly.

I'd also like to see Unix socket support at some point in the future, which would almost work out-of-the-box (Unix socket pretending to be TCP socket), except for accept() having incompatible address. I'd probably address this in the future by implementing abstract sockets that don't care about it.

What do you think?