8 ms·

Rustysd – A minimal drop-in for a subset of systemd in Rust

162 points by hu3 7y ago

techntoke 7y ago
Just because you coulda, doesn't mean you shoulda.
- gmueckl 7y ago
  If it fixes systemd legendary obesity and user hostility, why not?
- giancarlostoro 7y ago
  If you dont have constructive criticism then follow your own advice.
- coldtea 7y ago
  Holds for systemd replacements as well as for comments judging them!
littlestymaar 7y ago
The title here is a little questionable: this project is not an attempt to be a full replacement for systemd, but more a minimalist init system compatible with systemd. I much more like the title chosen by the author when he posted it on reddit earlier: “Rustysd: A systemd-compatible service manager written in rust”.[1] [1]: https://www.reddit.com/r/rust/comments/e9o724/rustysd_a_systemdcompatible_service_manager/ https://www.reddit.com/r/rust/comments/e9o724/rustysd_a_syst...
- hu3 7y ago
  That's my fault. I copied the title from /r/programming. Would be nice if a mod could fix the title.
  - dang 7y ago
    We've replaced the title with what the Github page says. Submitted title was "Rustysd – systemd replacement written in Rust"
equalunique 7y ago
Maybe a slimmed down version of systemd is what we really needed all along.
- marcosdumay 7y ago
  It doesn't even have to be slimmed down. It just have to be high quality.
  - cies 7y ago
    I'd say, more specifically, it has to be a lot more modular.
    - gmueckl 7y ago
      Modular in which sense? Clean interfaces between non-exchangeable modules or the actual ability to replace modules?
      - marcosdumay 7y ago
        Clean interfaces imply on exchangeable modules.
        gmueckl 7y ago
        Mo, they don't. They are merely a prerequisite. It must be reasonably possible to reimplement the module in question and it must be possible to instantiate that alternative implementation instead of the original one. A counter-example is to have all lodules linked into a single static binary. You may have a beautiful separation berween modules in there, but the static linking makes them an immutable bundle.
        cies 7y ago
        Thus "clean" interfaces make exchangeable modules possible. We still have to write them.
The_rationalist 7y ago
It's fascinating how much the rust community dedicate work to reinvent the wheel. Don't get me wrong, it's not always a bad thing, but I believe there are still a load of interesting types of software that almost doesn't exist, and such efforts would have better ROI on those new kinds of software e.g an hypergraph database or an NLP library that allows for any inflected word to get another inflection (e.g I give in parameters input="be", kind=verb, time=present, person= 3rd plural) and it output "are".
- marcosdumay 7y ago
  The ROI on improving widely used tools is quite large. And for most of them just being in a memory-safe language is already a large improvement. Not everybody wants to work on hot new things, some want focus on having their tools to stable and working as designed. We need both kinds of work.
  - The_rationalist 7y ago
    I agree and I disagree. The ROI on improving widely used tools is quite large Yes indeed. You probably wanted to say: The ROI on reinventing widely used tools is quite large" There are some extremely used binaries that have a stagnant development and have not adapted to modern ergonomics. I beautiful example of that subset of widely used tools is cat. Cat is extremely used and yet, the rust rewrite bat is far superior, because among other things, it has color and code higlithing :0 For a rust rewrite to be successful you need the following conditions: You have ideas of improvments not present in the current tool. Your ideas are not on their roadmap. The current tool has not had too much of man/hours, which you can interpret heuristically as: the current tool has less than a few thousands of commits. Here we're talking about systemd which has 42,600 commits. By the time rustysd will have as much features as current* systemd, the original developer will be dead. As an end user I have almost zero benefits in this kind of rewrites, as I'm aware it's a far poorer software by design. If it was 1) a new kind of software or 2) a reimplementation of a tool that they can realistically manage to outcompete or 3) the development that will in the very longterm replace an old complex tool that has stopped development, then I would have been interested. Anyway if it's for fun/learning purpose, they do what they want, but utilitaristically there would be better choices.
monday_ 7y ago
I wonder if this will impact Debian's current debate [1] on init systems. A minimal systemd-compatible init system seems like a real contender here, and this project shows that there're both interest and capability for developing one. [1] https://www.debian.org/vote/2019/vote_002#textf https://www.debian.org/vote/2019/vote_002#textf
- uluyol 7y ago
  Tangential question: is rust usable for core parts of distributions like Debian that can run on a million architectures and even on different kernels? I hope to see more C code replaced by rust, but that seems difficult if portability to extremely niche systems is a requirement.
  - pabs3 7y ago
    rustc isn't available for all of Debian's unofficial architectures yet: https://buildd.debian.org/status/package.php?p=rustc https://buildd.debian.org/status/package.php?p=rustc Looks like there is a bootstrap issue, rustc build-depends on cargo, which build-depends on itself.
    - xvilka 7y ago
      mrustc[1] can help with this issue. [1] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- jml7c5 7y ago
  From the README: "For now that is just out of interest how far I could come with this and what would be needed to get a somewhat working system. It is very much a proof of concept." It's also only two months old. So I would say this a toy project. Of course, that it is a toy project right now does not preclude it becoming a real, robust init system in the future (just look at where the Linux kernel started, after all) but I do not think it is currently relevant to the Debian debate.
lez 7y ago
Yes! I'm very much supportant of this project. Running a monolithical christmas-tree isn't what we need as PID 1.
sansnomme 7y ago
The main issue with systemd is UX. The config files needs too many knobs for simple run-forever-in-background use cases and half of the time you get weird permission issues related to sudo. Documentation feels half baked and requires digging through manpages. A pm2-style init in Rust would be a lot better.
- jononor 7y ago
  What is wrong with it exactly? A typical unit file would for something that runs forever is something like this: [Unit] Description=This service runs always [Install] WantedBy=multi-user.target [Service] ExecStart=/usr/bin/python3 /opt/myapp/main.py Restart=always WorkingDirectory=/opt/myapp User=myuser Group=myuser You can skip the last 3 if you want.
  - Arnavion 7y ago
    If main.py crashes ~5 times within ~10 seconds, then it'll get put in a failed state until you manually recover it with `reset-failed`. systemd will be happy to restart it often enough that it hits that threshold, because you told it to. So just `Restart=always` isn't enough; you need to set `StartLimitBurst` too (and `StartLimitIntervalSec` if you want to fine-tune it).
  - jjoonathan 7y ago
    The systemd unit file isn't a cluster of half-baked utilities held together with spit and bailing wire, so naturally people hate it.
- gsich 7y ago
  On the contrary, it's surprisingly easy to create such a thing. You get logging for free too.
josteink 7y ago
Please note: this does not make use of Linux-specific features like cgroups. In my kind, that takes away one important m/killer feature which right now only systemd provides.
fefe23 7y ago
I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd). For comparison: ripgrep (Rust) is >2 MB stripped, GNU grep is <200k stripped. I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original. So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me. I'm sure the Rust people will at some point find a way to reduce the footprint of the runtime. Currently they have other, more pressing goals. Personally, I wrote my own init system. The PID 1 process is a 10k statically linked binary. Resident memory size is 24k on one of my AMD64 Linux production servers. That is what I think could rightfully be called a minimal subset.
- mmcallister 7y ago
  So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me. I understood it as as a subset of features. It doesn't seem to me that the author is trying to play code golf with their codebase, or optimize for binary size (and why would you in 2019, storage is cheap)
- reificator 7y ago
  > I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd). > I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original. Isn't this simply a result of the C runtime not being bundled with the executable? How does the comparison look when accounting for that difference?
  - Gibbon1 7y ago
    C does type erasure, doesn't do runtime checking and maps most everything to assembly. I haven't checked recently but last time I did Rust's bare metal binaries were larger than C ones. Might be better now. That said you can beat C's code size with hand assembly and p-code interpreters.
jonny383 7y ago
Cool project, congrats to the author for getting a system tool so far in Rust. Just a couple of years ago that seemed questionably difficult but here we are. I do have to ask though, does this serve any improvement over or fix any of the shortcomings of systemd aside from being written in Rust?

162 points by hu3 7y ago

techntoke 7y ago

Just because you coulda, doesn't mean you shoulda.

gmueckl 7y ago
If it fixes systemd legendary obesity and user hostility, why not?
giancarlostoro 7y ago
If you dont have constructive criticism then follow your own advice.
coldtea 7y ago
Holds for systemd replacements as well as for comments judging them!

littlestymaar 7y ago

The title here is a little questionable: this project is not an attempt to be a full replacement for systemd, but more a minimalist init system compatible with systemd. I much more like the title chosen by the author when he posted it on reddit earlier: “Rustysd: A systemd-compatible service manager written in rust”.[1] [1]: https://www.reddit.com/r/rust/comments/e9o724/rustysd_a_systemdcompatible_service_manager/ https://www.reddit.com/r/rust/comments/e9o724/rustysd_a_syst...

hu3 7y ago
That's my fault. I copied the title from /r/programming. Would be nice if a mod could fix the title.
- dang 7y ago
  We've replaced the title with what the Github page says. Submitted title was "Rustysd – systemd replacement written in Rust"

equalunique 7y ago

Maybe a slimmed down version of systemd is what we really needed all along.

marcosdumay 7y ago
It doesn't even have to be slimmed down. It just have to be high quality.
- cies 7y ago
  I'd say, more specifically, it has to be a lot more modular.
  - gmueckl 7y ago
    Modular in which sense? Clean interfaces between non-exchangeable modules or the actual ability to replace modules?
    - marcosdumay 7y ago
      Clean interfaces imply on exchangeable modules.
      - gmueckl 7y ago
        Mo, they don't. They are merely a prerequisite. It must be reasonably possible to reimplement the module in question and it must be possible to instantiate that alternative implementation instead of the original one. A counter-example is to have all lodules linked into a single static binary. You may have a beautiful separation berween modules in there, but the static linking makes them an immutable bundle.
        cies 7y ago
        Thus "clean" interfaces make exchangeable modules possible. We still have to write them.

The_rationalist 7y ago

It's fascinating how much the rust community dedicate work to reinvent the wheel. Don't get me wrong, it's not always a bad thing, but I believe there are still a load of interesting types of software that almost doesn't exist, and such efforts would have better ROI on those new kinds of software e.g an hypergraph database or an NLP library that allows for any inflected word to get another inflection (e.g I give in parameters input="be", kind=verb, time=present, person= 3rd plural) and it output "are".

marcosdumay 7y ago
The ROI on improving widely used tools is quite large. And for most of them just being in a memory-safe language is already a large improvement. Not everybody wants to work on hot new things, some want focus on having their tools to stable and working as designed. We need both kinds of work.
- The_rationalist 7y ago
  I agree and I disagree. The ROI on improving widely used tools is quite large Yes indeed. You probably wanted to say: The ROI on reinventing widely used tools is quite large" There are some extremely used binaries that have a stagnant development and have not adapted to modern ergonomics. I beautiful example of that subset of widely used tools is cat. Cat is extremely used and yet, the rust rewrite bat is far superior, because among other things, it has color and code higlithing :0 For a rust rewrite to be successful you need the following conditions: You have ideas of improvments not present in the current tool. Your ideas are not on their roadmap. The current tool has not had too much of man/hours, which you can interpret heuristically as: the current tool has less than a few thousands of commits. Here we're talking about systemd which has 42,600 commits. By the time rustysd will have as much features as current* systemd, the original developer will be dead. As an end user I have almost zero benefits in this kind of rewrites, as I'm aware it's a far poorer software by design. If it was 1) a new kind of software or 2) a reimplementation of a tool that they can realistically manage to outcompete or 3) the development that will in the very longterm replace an old complex tool that has stopped development, then I would have been interested. Anyway if it's for fun/learning purpose, they do what they want, but utilitaristically there would be better choices.

monday_ 7y ago

I wonder if this will impact Debian's current debate [1] on init systems. A minimal systemd-compatible init system seems like a real contender here, and this project shows that there're both interest and capability for developing one. [1] https://www.debian.org/vote/2019/vote_002#textf https://www.debian.org/vote/2019/vote_002#textf

uluyol 7y ago
Tangential question: is rust usable for core parts of distributions like Debian that can run on a million architectures and even on different kernels? I hope to see more C code replaced by rust, but that seems difficult if portability to extremely niche systems is a requirement.
- pabs3 7y ago
  rustc isn't available for all of Debian's unofficial architectures yet: https://buildd.debian.org/status/package.php?p=rustc https://buildd.debian.org/status/package.php?p=rustc Looks like there is a bootstrap issue, rustc build-depends on cargo, which build-depends on itself.
  - xvilka 7y ago
    mrustc[1] can help with this issue. [1] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
jml7c5 7y ago
From the README: "For now that is just out of interest how far I could come with this and what would be needed to get a somewhat working system. It is very much a proof of concept." It's also only two months old. So I would say this a toy project. Of course, that it is a toy project right now does not preclude it becoming a real, robust init system in the future (just look at where the Linux kernel started, after all) but I do not think it is currently relevant to the Debian debate.

lez 7y ago

Yes! I'm very much supportant of this project. Running a monolithical christmas-tree isn't what we need as PID 1.

sansnomme 7y ago

The main issue with systemd is UX. The config files needs too many knobs for simple run-forever-in-background use cases and half of the time you get weird permission issues related to sudo. Documentation feels half baked and requires digging through manpages. A pm2-style init in Rust would be a lot better.

jononor 7y ago
What is wrong with it exactly? A typical unit file would for something that runs forever is something like this: [Unit] Description=This service runs always [Install] WantedBy=multi-user.target [Service] ExecStart=/usr/bin/python3 /opt/myapp/main.py Restart=always WorkingDirectory=/opt/myapp User=myuser Group=myuser You can skip the last 3 if you want.
- Arnavion 7y ago
  If main.py crashes ~5 times within ~10 seconds, then it'll get put in a failed state until you manually recover it with `reset-failed`. systemd will be happy to restart it often enough that it hits that threshold, because you told it to. So just `Restart=always` isn't enough; you need to set `StartLimitBurst` too (and `StartLimitIntervalSec` if you want to fine-tune it).
- jjoonathan 7y ago
  The systemd unit file isn't a cluster of half-baked utilities held together with spit and bailing wire, so naturally people hate it.
gsich 7y ago
On the contrary, it's surprisingly easy to create such a thing. You get logging for free too.

josteink 7y ago

Please note: this does not make use of Linux-specific features like cgroups. In my kind, that takes away one important m/killer feature which right now only systemd provides.

fefe23 7y ago

I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd). For comparison: ripgrep (Rust) is >2 MB stripped, GNU grep is <200k stripped. I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original. So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me. I'm sure the Rust people will at some point find a way to reduce the footprint of the runtime. Currently they have other, more pressing goals. Personally, I wrote my own init system. The PID 1 process is a 10k statically linked binary. Resident memory size is 24k on one of my AMD64 Linux production servers. That is what I think could rightfully be called a minimal subset.

mmcallister 7y ago
So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me. I understood it as as a subset of features. It doesn't seem to me that the author is trying to play code golf with their codebase, or optimize for binary size (and why would you in 2019, storage is cheap)
reificator 7y ago
> I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd). > I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original. Isn't this simply a result of the C runtime not being bundled with the executable? How does the comparison look when accounting for that difference?
- Gibbon1 7y ago
  C does type erasure, doesn't do runtime checking and maps most everything to assembly. I haven't checked recently but last time I did Rust's bare metal binaries were larger than C ones. Might be better now. That said you can beat C's code size with hand assembly and p-code interpreters.

jonny383 7y ago

Cool project, congrats to the author for getting a system tool so far in Rust. Just a couple of years ago that seemed questionably difficult but here we are. I do have to ask though, does this serve any improvement over or fix any of the shortcomings of systemd aside from being written in Rust?