What automatic integration with systemd could look like?


#1

I thought it would be cool if there was a tool that can automatically hook up Rust binaries with systemd, based on Cargo data.

e.g. you’ve written a web server, you run cargo integrate-with-systemd, magic happens, and your server is correctly set up to automatically start via systemd integration, with logging, restarting, etc. Data is taken from Cargo.toml and you don’t need to mess with config files.

However, I’m not sure how far to take that magic part.

  • should it use current binary path, in ./target/release, or rather copy it to some more appropriate place like /usr/local/bin?

  • if it installs binaries, should it build a .deb package for them first, and install that package, so they’re properly installed?

  • Should it scan your dependencies to figure out more advanced config? e.g. set up logging if you use the log crate? Or configure the service to wait for network if it sees you use hyper?


#2

I love this. I struggled with this when I made my blog using Rust & Rocket. I really think there should be better guides/tutorials/tools for making web apps using Rust. If you’ve never had to setup a reverse proxy before it can be confusing at first.

You could add commandline options, make the default invocation ask you questions to determine its behavior and have optional commandline args to specify specific behavior and skip the questions.


#3

This should probably be via the snap format, for easier cross-platform support and more self-contained packaging / paths etc. IIUC correctly, one of the key goals of that format is to make packaging and start/stop integration easier and consistent (ie, minimising the amount of magic).


#4

Unfortunately snapcraft doesn’t work on my VPS (for reasons that are off-topic here), so I’m not exploring that solution.


#5

This would be very interesting also in the context of being part of a (cargo-subcommand) tool that builds .deb or .rpm files.

(For CLI tools, we’ve focused on being able to create shell completions and man pages, but for daemons/services generating .service files is quite important, too.)


#6

Creating a port of https://github.com/mafintosh/add-to-systemd would probably be a good place to start. The minimal template is fairly small, and could probably be neatly wrapped in a Builder library.


#7

So I’m seeing two possibilities. I’ll probably implement both:

  1. Integrate with cargo-deb, pick some vaguely sensible defaults, and build & install in one go. That’s going to be the fast way for “I have source code, I want this running on this machine”.

  2. Generate a well-commented template to manually customize, put it somewhere in src/ for example. systemd has lots of options you may want to tweak for serious deployment, and very little of that is in Cargo’s metadata.

In my case, I really wanted the first, but ended up doing the second :slight_smile:


#8

Despite their marketing saying otherwise, Ubuntu is the only platform that really uses/supports the snap format. We already have tools for packaging, like cargo-deb for example.