systemd service support

[jabedude]

@Michael-F-Bryan asked about systemd support in #42 and you mentioned opening an issue if anything was needed. Systemd supports socket activated services, services that are lazily started when a client connects to a desired UNIX/TCP/fifo endpoint. libsystemd provides methods for systemd enabled services to receive the activated socket file descriptor such as sd_listen_fds. Rust socket activated daemons would need to call the C API to receive a systemd file descriptor. I wrote a tiny crate that provides that functionality in pure rust, would you be interested in either using it in spirit or merging that crate into this project? I wouldn't mind "donating" it, it's quite simple and it's only purpose is to make writing rust daemons easier (just like spirit :) )

[vorner]

Hello

Before jumping to conclusions, I'd like to know how that would fit into spirit. It would certainly not be part of the base spirit, it would have to be some kind of spirit-systemd-sockets or such. But still, how do you propose this would get integrated? How do these sockets get updated if the configuration changes? Etc… so, do you have a proposal for how the interface would look like?

Is that functionality actually used in practice, or is it one of these clever ideas that never got any traction? What's the advantage over just having a daemon listen to the sockets itself?

Can you link your crate you mentioned? I'd probably not want to merge it, as it could be useful separately and also I try to not inflate spirit itself too much if possible.

[jabedude]

How do these sockets get updated if the configuration changes?

If the service's systemd unit file is updated, then systemd handles restarting the service.

Is that functionality actually used in practice, or is it one of these clever ideas that never got any traction?

Definitely. avahi, cups, and docker all use socket activation. This article: http://0pointer.de/blog/projects/socket-activation.html covers the benfits of socket activation: easier service parallelization, service persistence, easier service upgrades, etc.

Can you link your crate you mentioned?

Sure, here it is: https://github.com/jabedude/sd-daemon-rs/. It's very simple, but its necessary for systemd daemons who want to go the socket activation route.

[vorner]

I'm reading through the article and through your responses. I'm still not sure how this should interact with spirit, if at all. I mean, spirit is mainly about reading arguments and configuration and being able to adapt to the configuration at runtime.

The sockets from systemd would not be coming from configuration or command line, this seems to be somewhat orthogonal to spirit. I mean, you can have a service that uses both spirit and your library, or just one of them.

But maybe I'm still not seeing something. Could you maybe provide a snippet/example service and show how that would tie together? And what the advantage over using both spirit and your library but without any direct interaction would be?

If the service's systemd unit file is updated, then systemd handles restarting the service.

That's actually quite the opposite to what spirit tries to do. Let me explain with an example. If you have a database server or a DNS resolver, it takes quite some time to start or to get to its full performance, because it fills caches (either from the disk or by asking authoritative DNS servers as it processes requests). So one wants to keep it running and not restart it when the configuration needs to be changed. Spirit allows, in some cases and with some assistance, to be able to change the configuration at runtime ‒ including things like sockets it listens on.

And I don't quite buy the things with seamless upgrades the article describes. If I'm a database server and I get restarted, it doesn't really help that the listening socket got preserved and that no new connection got lost during the time. The real trouble is killing all the long-term connections with the old instance ‒ which systemd doesn't seem to help in any way.

Nevertheless, I'm not against adding any meaningful support. After all, not all services are database servers. But I still don't understand how it would fit with spirit.

As for your library, I like how small and minimal it is, it seems nice :-). I guess there's still some work to be done (like, adding documentation or providing some real tests). But I'd suggest you eventually publish it as a separate crate. After all, even if it gets integrated into spirit somehow, people still might want to use it separately too.

[jabedude]

I was imagining having an extension for the spirit builder to maybe have the daemon configuration also receive activated sockets. A service should be able to use either or both spirit and my crate, so I guess adding this functionality isn't necessary.

Thank you, I have some uncommitted changes and then I will publish it :)

[vorner]

So, do you think this can be closed as there's nothing to be done on spirit's side?

[jabedude]

Yes, if I think of any other systemd compatibility issues I'll open another issue!