Systemd .socket units allow to start services on demand by passing sockets as inherited file descriptors.

I didn't know systemd could to that. This is a bit like inetd?

This could probably do with some docs on how you'd set the systemd unit up .

Would rclone be be expected to exit after some inactivity or does systemd desk with that?

This commit detects the first socket passed by Systemd and adds it as server listener, like an --addr command line argument

Why only the first?

Can you think of a way of unit testing this?

I didn't know systemd could to that. This is a bit like inetd?

Yes, it's like that :)

This could probably do with some docs on how you'd set the systemd unit up .

Systemd docs are good on its part. I tried to write an example to shed light on the rclone serve side.

Would rclone be be expected to exit after some inactivity or does systemd desk with that?

It's a nice idea, it could be a good improvement. I warn you: if you'd like to see it in this PR, I need some guidance to implement it!

Why only the first?

Good question, I rewrote the code to support multiple ports. I tried to fix the failing Windows build too.

Can you think of a way of unit testing this?

I'm not a Golang expert, I don't know how to implement such tests. However to create a mock environment we'd need to open some additional file descriptors and set LISTEN_FDS in the environment.

Detailed description here: https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html#

Check lights are green 🎉

From here we could add

• automatic rclone exit after inactivity timeout
• automated tests

As said I'd need a bit of help for both to understand how to do them and where to start: should I ask for help on the forum?

I just stumbled over this, while looking at #7801. Didn't see it before.

This PR seems stale and would need a rebase too.

@DavidePrincipi can you take a look at the other PR? Any preference on one vs. the other?

Hi @flokli,

Thanks for your question!

I'm not entirely sure. The first commit of PR 7801 appears to address the same issues as this PR, but it also includes SFTP and an inline help fix. I'm open to closing this PR, but I have a couple of questions for you.

• In my PR, the --addr option is always required to enable or disable TLS with the tls:// address prefix. How can I decide if I want TLS with your commit?

• As Nick already mentioned, with both PRs, if we start Rclone when the first connection is established, we should also implement a way to exit after some inactivity. Do you have any plans for this additional feature?

In my PR, the --addr option is always required to enable or disable TLS with the tls:// address prefix. How can I decide if I want TLS with your commit?

In my case, I have a (more complicated) reverse proxy setup in front that does TLS termination, and in the background, for some routes, it'd connect to a unix domain socket (which would be socket-activated). Indeed having a socket-activated tcp socket, and doing tls with restic directly is also a usecase which would not work like this. I'm unsure what'd be the best way forward, but I feel it should be aligned and consistent across all "server endpoints".

As Nick already mentioned, with both PRs, if we start Rclone when the first connection is established, we should also implement a way to exit after some inactivity. Do you have any plans for this additional feature?

In a socket-activated context, shutting down after some inactivity makes sense if the process is used very rarely. While it "only really makes sense" in a socket-activated context however, I think just socket-activation itself is a big feature on its own, as it greatly simplifies zero-downtime reconfiguration and service dependency graphs.

I don't think we should make "shutdown after inactivity" a requirement for socket-activation, nor a default. There's definitely usecases where I'd want socket-activation alone (for the reasons mentioned above), but no shutdown after inactivity (because recreating all in-memory state might be slow, and responding fast is critical). I really see these as two orthogonal things, and socket-activation a dependency of it.

Thanks for your detailed response!

I'm unsure what'd be the best way forward, but I feel it should be aligned and consistent across all "server endpoints".

To recap, this PR lacks SFTP socket activation, while PR 7801 cannot enable TLS. Do I understand this correctly?

For my use case, TLS is not important right now because connections are over a trusted VPN. As mentioned, we can go with PR 7801 and close this one.

I don't think we should make "shutdown after inactivity" a requirement for socket-activation, nor a default.

Agreed 👍

@ncw if you feel this PR is not needed we can close it! Thank you!

To recap, this PR lacks SFTP socket activation, while PR 7801 cannot enable TLS. Do I understand this correctly?

Yes.

@DavidePrincipi I got confused, PR 7801 does allow TLS.

It does look at the TLS config, and if that's set, does configure TLS. The only thing it doesn't do any more is allowing you to pass two different listeners via socket-activation, and configure one with TLS, and one without.