Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

71–80 of 308 posts

Re: Why systemd is a problem for embedded Linux

#71
post #40

Not really embedded, but one of the easier classes of wins I've had over the years is moving prod servers to a non-systemd Gentoo. Random (rare) 200ms latency spikes and whatnot just disappear, and the system jitter drops down to the tens of microseconds range, significantly improving the qualitative performance of basically every piece of software I care about.

Did you ever dig in to see why that changed? I'm surprised that in a steady-state (not booting or restarting services) systemd/not-systemd would have an impact.

Re: Why systemd is a problem for embedded Linux

#72
post #30

> With care, though, a minimal installation of systemd does run on a low-resource ARM board like the Pi 3. In fact, it will run on a board with 1Gb RAM, perhaps even lower. Come fucking on. I ran systemd on a 32Mb MIPS board (RouterBoard from Mikrotik) just fine. The RES column is incredibly misleading in this case, because systemd is the first app in the system. So it gets charged for loading the entire glibc and th…

systemd itself is also large in storage size(8MB?), which is why openwrt has its own procd replacements, and yocto is not default to systemd either due to this. additionally, systemd does not work well with musl which is very popular in embedded linux.

systemd binary is around 1.5Mb, with the shared libsystemd it's around 2.5Mb. Both can be reduced by not including compressors (the infamous libz), audit libraries, SELinux, etc.

The minimum binaries size that can be obtained by trivial removals is around 2Mb.

OpenWRT should just stop being stubborn and integrate it. They dropped support for 4Mb devices loooooong ago, and recently bumped the minimum specs to 16Mb.

> systemd does not work well with musl which is very popular in embedded linux.

Systemd can work with musl with a small compatibility shim, I did it about 9 years ago. Somebody did that again: https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-...

Re: Why systemd is a problem for embedded Linux

#73
post #39

Earlier quoted context omitted.

What do you imagine this proves or disproves? How many people eat McDonalds? Or buy in to countless other things that can be trivially demonstrated to be against their own interests. I don't know about anyone else but I never heard the critiques of systemd to be based on any doomsday predictions. Everyone knew it would function, and that it even serves one use case better than before. The critique was only ever that…

> How many people eat McDonalds? If you’re already starting like this it’s obvious that the following text will be non-scientific non-sense. As a reminder: There is no such thing as “healthy food” and “unhealthy food”, there is just healthy and unhealthy nutrition. Still baffles me that people think it would actually be legal to sell actual unhealthy food, i.e. poisonous food. Also, “organic food” is just a marketing…

Non organic food is very obviously a poison for the vast majority of Earth's life.

See : the current apocalyptic and accelerating global biomass destruction directly caused by industrial farming.

Re: Why systemd is a problem for embedded Linux

#74

I couldn't disagree more: I've worked with lots of embedded devices running systemd, and it solves many more problems than it introduces. The community is also quite responsive and helpful in my experience. I won't pretend there aren't occasional weird problems... but there's always a solution, here's a recent example: https://github.com/systemd/systemd/issues/34683 Memory use is irrelevant to me: every embedded Linu…

That "occasional weird problem" is because systemd is not designed to be used with other software. While you technically still have the choice to roll your own non-systemd initramfs, it will be an uphill battle.

Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine

Re: Why systemd is a problem for embedded Linux

#75
I've had very nice experiences using systemd for developing embedded systems. Laying out all the unit files and just slapping the files in an overlay makes it super simple.

The RAM usage isn't being calculated correctly. You can easily run systemd on very limited systems.

Re: Why systemd is a problem for embedded Linux

#76
post #32

The article fails to mention another aspect of systemd that interferes with emmbedded dvelopment: it's utility applications (primarily systemctl, but all the others as well) are intended to be run on the booted system for which the control is being performed. When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment…

> When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment. There is systemd-firstboot, etc, but this is not as convenient as just being able to set config options on the mounted (non-booted) embeddded media.

systemctl --root /path/to/sd/card/

Re: Why systemd is a problem for embedded Linux

#77

OpenEmbedded/Yocto, Devuan and Gentoo provide multiple init systems. systemd CVEs: https://ubuntu.com/security/cves?package=systemd&limit=100 Rust PoC: https://github.com/KillingSpark/rustysd > Rustysd is a service manager that tries to replicate systemd behaviour for a subset of the configuration possibilities. It focuses on the core functionality of a service manager, not requiring to be PID1 (aka init process).. c…

How many systemd CVEs are memory or thread safety related?

Re: Why systemd is a problem for embedded Linux

#78
post #39

Earlier quoted context omitted.

What do you imagine this proves or disproves? How many people eat McDonalds? Or buy in to countless other things that can be trivially demonstrated to be against their own interests. I don't know about anyone else but I never heard the critiques of systemd to be based on any doomsday predictions. Everyone knew it would function, and that it even serves one use case better than before. The critique was only ever that…

> How many people eat McDonalds? If you’re already starting like this it’s obvious that the following text will be non-scientific non-sense. As a reminder: There is no such thing as “healthy food” and “unhealthy food”, there is just healthy and unhealthy nutrition. Still baffles me that people think it would actually be legal to sell actual unhealthy food, i.e. poisonous food. Also, “organic food” is just a marketing…

Please explain to me how farmers who are making organic food are performing a scam.

The fact that you don’t like how organic food is marketed does not mean it is full bore a scam. It’s a real agricultural practice that exists. Organic eggs require far more freedom for chickens for example.

Re: Why systemd is a problem for embedded Linux

#79

I'm quite annoyed by the bland statement in the introduction of this article: people make about it don’t stand up to much scrutiny, even the technical ones Basically the author says that everyone else has stupid rants that doesn't stand but himself has valid claims so that in the end we have a proof that there are a few valid technical rants! That being said, the main problem with systemd from the beginning is that i…

And systemd replace all POSIX init system because they were all bad or systemd do the same thing better or faster, your point is a good argument against following POSIX religiously

Re: Why systemd is a problem for embedded Linux

#80
post #36
post #31

Earlier quoted context omitted.

The thing is, the good things are the things you don't notice; the things that just work. They didn't used to "just work" like that before systemd. System boot is faster. I can have fewer things started up in the background, and instead have them start up when needed. Restarting services works consistently. Every application doesn't have its own bespoke and half baked management scripts which don't work half the time…

> the good things are the things you don't notice; the things that just work sorry, no, at least in any meaningful sense, because init already just worked for me. and when something didn't, I could find how to fix it in a way that was transparent and I understood and could even modify or make better, without being connected to the internet looking for cargo cult incantations on stack overflow init was a tool; systemd…

Okay, I'll bite.

What kind of problems do you have with the part of systemd that replicates sysvinit /every other day/?

Post reply on HN