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

https://github.com/KillingSpark/rustysd

by hu3 • 7 years ago

162 75 7 years ago

github.com

techntoke• 7 years ago

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

gmueckl3• 7 years ago

If it fixes systemd legendary obesity and user hostility, why not?

giancarlostoro• 7 years ago

If you dont have constructive criticism then follow your own advice.

coldtea• 7 years ago

Holds for systemd replacements as well as for comments judging them!

littlestymaar• 7 years 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_syst...

hu3• 7 years ago

That's my fault. I copied the title from /r/programming.

Would be nice if a mod could fix the title.

dang3• 7 years ago

We've replaced the title with what the Github page says.

Submitted title was "Rustysd – systemd replacement written in Rust"

equalunique• 7 years ago

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

marcosdumay5• 7 years ago

It doesn't even have to be slimmed down. It just have to be high quality.

cies2• 7 years ago

I'd say, more specifically, it has to be a lot more modular.

inopinatus3• 7 years ago

The real systemd is the programming language we made along the way.

etaioinshrdlu• 7 years ago

You mean the internal libraries that are reused throughout systemd?

agumonkey• 7 years ago

I always thought systemd would be a messy pioneering attempt that would be redesigned later on. Because dependency based parallel boot is a good thing.

pdkl95• 7 years ago

What features would a "slimmed down version of systemd" provide that isn't available in various independent tools we used to use (and still use today).

* Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.

* journald? Logging tools - including multiple types of syslog daemons - are numerous; use whatever you want. Choice is good. Even journald could be an option some people might prefer If it wasn't monolithically tied to systemd and could be used as a stand-alone daemon.

* cgroups? Other managers exist.

* timedated? Managing the clock was never difficult. The standard solution is to delegate most/all clock management to ntpd. If you had especially unusual needs, you probably had to set it up manually anyway (probably with a tiny amount of sh script).

* udevd? Other hardware managers exist. Some of us prefer the peace-of-mind of a simple static configuration instead of a manager, but you should be able to use udevd if you prefer it; udevd used to work stand-alone, but Lennart added it to the systemd monolith[1] when they were trying to push kdbus into the kernel. -sigh-

* daemon/process management? daemontools, runnit, s6, etc.

* logind? This attempts to create the concept of a "session" as a privilege boundary that is orthogonal to the actual privilege boundary in UNIX: the UID. The entire concept is a terrible security problem waiting to happen. The entire concept of a session is especially stupid considering most people don't actually use the traditional multiuser features of UNIX or this new "session" concept. In the rare situation where someone actually is running an actual multiseat setup, an extra step to install an optional package with these features wouldn't be a burden. The rest of just need a simple login/password prompt that can launch gnome/kde/.xinitrc/whatever at login time, which already existed as {x,g,sd,lx}dm.

If there are features that were only provided by systemd, is a monolithic[1] daemon really the best solution? Or could those feature simply be encapsulated into a small stand-alone package that could work wherever it is needed?

edit:

[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256

viraptor• 7 years ago

cgroups? Other managers exist.

For resource quotas? Cgroups is a kernel interface. What kind of manager do you have in mind?

daemon/process management? daemontools, runnit, s6, etc.

None of them can deal with runaway daemons. Some of them can deal with ordering and pre/post conditions and instancing, but not as extensively. Each provides a different subset of systemd's init features.

Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.

Inetd works in entirely different way. Those approaches are not comparable at all. (Systemd can hand off the whole listening socket)

jcelerier• 7 years ago

All of the tools you mentioned have different syntaxes. With sd I onlt have to keep a single syntax - ini files - which is incredibly more efficient than ten years ago when I had to memorize a dozen different things to make my system run. I'd rather slit my wrists than write another init script in bash / dash, even for the simplest service.

sterlind• 7 years ago

Systemd's real value proposition is its tight coupling. As you pointed out, there were several logging systems, several daemon programs, several hardware managers, a combinatorial smorgasbord of options available.

This means you can't assume almost anything about the distro or setup you're targeting as an application developer. Should I log to /var/log or use journald? Can I bundle a .service file or should I have shell scripts? Can I rely on udev rules or do I need to touch /dev? You can't assume unless you're only targeting Ubuntu.

Systemd is so integrated that programs require minimal porting. The alternative is either supporting everything, which leads to massive bloat, or forcing downstream patches to make the damn thing compile and run. Having a non-modular set of services you can rely on means even small alternative distros like NixOS can support many packages, because those packages require minimal changes.

Consistency across environments is critical. it's why docker is so big - all the wiring lives in one place, and what's inside runs everywhere.

But reducing choices to get consistency and consensus strips away the freedom that Linux offered - you can't uproot and replace components as easily. You can have that freedom or you can have a hassle-free package ecosystem; it's an inherent trade-off.

JdeBP2• 7 years ago

I suggest that you go and look at the history of what happened with uselessd .

The_rationalist4• 7 years 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".

marcosdumay5• 7 years 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_rationalist4• 7 years 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.

tus88• 7 years ago

Rust was created to replace C, not build anything radically new or different.

inopinatus3• 7 years ago

This is the wheel of progress.

gabcoh• 7 years 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 sounds to me like this was more of a project that was just for fun and not really meant to be a genuine attempt at producing an alternative to systemd.

tracker1• 7 years ago

Some of the best and most lasting systems start out this way.

chc• 7 years ago

Yes, but you need to be an expert in NLP to write that NLP library. People in their free time write software that sits at the intersection of interesting and able.

The_rationalist4• 7 years ago

Well said :)

rektide• 7 years ago

On the one hand yes there's tons to explore, so many promising futures.

But I would like to keep an open mind about works like this one. This is work that could beget all kinds of neat things! Systemd targets Linux, where as this is a bit higher level & might be portable to other environments. It allows other people to not have to create their own process management systems, not have to create their own init system. The recreation brings the availability of the giant's shoulder to many many more places, distributes it's promise to really new & interesting targets.

enriquto• 7 years ago

Technology advances by the continued reinvention of the wheel. As much as I dislike Rust the language, these activities of the Rust community are spot on.

monday_2• 7 years ago

I get your sentiment, but creating a minimalist, but compatible alternative to systemd in a safe language is anything but reinventing the wheel. There's a real concern with systemd's feature creep, it's defaults, security and a development culture. rustysd may be a proof of concept, but it addresses real issues.

StreamBright• 7 years ago

Exactly, like the borrow checker. Ohh, wait.

CamouflagedKiwi• 7 years ago

It's pretty likely that the people writing an init system in Rust are not just gonna casually decide to write an advanced NLP library instead, since it requires a fairly distinct set of interests and skills.

monday_2• 7 years 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

uluyol• 7 years 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• 7 years ago

rustc isn't available for all of Debian's unofficial architectures yet:

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.

jml7c5• 7 years 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• 7 years ago

Yes! I'm very much supportant of this project.

Running a monolithical christmas-tree isn't what we need as PID 1.

sansnomme• 7 years 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• 7 years 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• 7 years 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).

gsich• 7 years ago

On the contrary, it's surprisingly easy to create such a thing. You get logging for free too.

josteink• 7 years 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• 7 years 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• 7 years 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)

reificator2• 7 years 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• 7 years 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.

nwmcsween• 7 years ago

Depends obviously but in general small, busybox is statically linked that uses a relatively large swath of libc and you can compare different libc versions somewhat by looking at the tags here: https://hub.docker.com/_/busybox?tab=tags. If parent was correct you could link all of musl libc and have 1.3MB or so left over for an actual application.

It also depends on the how the code is structured, musl for example is structured not to pull in unneeded objects while the size of the glibc docker container speaks for itself.

jonny383• 7 years 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?

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

Related Stories