
Rustysd – A minimal drop-in for a subset of systemd in Rust - hu3
https://github.com/KillingSpark/rustysd
======
monday_
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
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
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
mrustc[1] can help with this issue.

[1]
[https://github.com/thepowersgang/mrustc](https://github.com/thepowersgang/mrustc)

------
josteink
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.

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

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

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

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

~~~
pdkl95
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](https://news.ycombinator.com/item?id=19024256)

~~~
jcelerier
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.

~~~
mindslight
"ini files" are as much of a single syntax as sexprs are.

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

------
littlestymaar
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...](https://www.reddit.com/r/rust/comments/e9o724/rustysd_a_systemdcompatible_service_manager/)

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

Would be nice if a mod could fix the title.

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

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

------
The_rationalist
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
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
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.

~~~
Drdrdrq
> 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.

I think you are missing the point completely. We are talking about _rust_ ,
memory safe performant language, and _systemd_ , core system in many Linux
distributions, written in C++. I would _love_ to be able to replace systemd
(and kernel and core libraries too) with something that was safer at least in
this aspect (memory safety).

Big kudos to Mozilla for identifying the cause of many security bugs and for
finding a way to solve it while keeping performance intact.

~~~
johnr2
> systemd, core system in many Linux distributions, written in C++

s/C++/C

~~~
adev_
Yep, systemd is in plain old C....I wish it would be in C++....

Most of the security vulnerabilities reported
([https://www.cvedetails.com/product/38088/Freedesktop-
Systemd...](https://www.cvedetails.com/product/38088/Freedesktop-
Systemd.html?vendor_id=7971)) would not have existed in modern C++. Including
all the heavy ones implying stack smash due to VLA buffers that do not exist
in C++.

Many will hate me for that, but preferring old-C over C++ for a system
software after 2011 is a non-sense. Even the maintainers of GCC understood
that.

------
fefe23
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.

~~~
reificator
> _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?

~~~
nwmcsween
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](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.

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

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

