Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

221–230 of 308 posts

Re: Why systemd is a problem for embedded Linux

#221
post #207

Earlier quoted context omitted.

> My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended That’s an issue with a daemon, not systemd. Anyone who used NFS saw that routinely on SysV init during the era when Red Hat distributions shut down networking before ensuring that the network mounts were unmounted.

I regularly see it also on a system not using NFS, and it seems related to console seats. Never went to the bottom of it because it's sporadic/non-reproducible.

Yes - my point was simply that the shut down process tells things to stop but most sysadmins have war stories about that not working well for all kinds of things.

The problem is that there isn’t a universally correct way to do this: if my web server has hung, SIGKILL is what I want to get the system back in a usable state as quickly as possible but if it’s a file system, database, etc. you have questions like losing data which aren’t trivial to answer (e.g. if it’s a transient error, waiting for it flush is good but if my storage had an irrecoverable error I might want write off that data as lost and focus on getting the service back up).

Re: Why systemd is a problem for embedded Linux

#222
post #200

Earlier quoted context omitted.

My TP-Link MR3020 from around 2015 only has 4^H 16 MB of ram (4 MB flash) and thus cannot even run OpenWRT anymore.

I’ve still got two MR3040. TP-Link hasn’t released any update for them in years. You can run an older version of OpenWrt on them, but there’s no real point. These things don’t even support 5GHz WiFi.

I've got a few devices that only support 2.4 B/G. They're not in common use, but using an equally legacy router is the only way for them to connect.

Re: Why systemd is a problem for embedded Linux

#223

Earlier quoted context omitted.

How many systemd CVEs are memory or thread safety related?

I'd bet you get more CVEs and actual remote exploit entry points by systemd forcing mdns, bonjour, upnp and other zero conf hacks just because that was the work the systemd team was doing in rh before.

remembered another one. They use the same code for VM and bare metal. Including the easy-login convenience hacks.

So now anyone wanting physical access to your host, just have to intercept plain-text communication with the BIOS (after secureboot did its thing), and reply with a new root password when the OS request bios key 11 or something. evil maids are living the dream.

Re: Why systemd is a problem for embedded Linux

#224

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…

Anything mass produced is going to be pressured to reduce BOM cost, RAM capacity is still and will continue to be a prime target.

Re: Why systemd is a problem for embedded Linux

#225

Earlier quoted context omitted.

> systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing And it's slow. Windows 11 boots in 5 seconds on my laptop, Ubuntu 22 used to take about a minute before I finally made the switch.

> Windows 11 boots in 5 seconds on my laptop Try measuring a reboot instead. On modern Windows versions with “fast startup” enabled, the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down. (This is important if you dual boot, because it means you can’t safely access the Windows partition in the interim.)

> the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down

I'm okay with that. How do I enable this on Ubuntu?

Re: Why systemd is a problem for embedded Linux

#226
post #189

Earlier quoted context omitted.

Do you have some examples? I have a very hard time imagining a modern Wifi router supporting the latest standards and IPv6, admin web interface and so on running on 16 MB of RAM. I also have issue with "wifi routers in Europe are all 16 or 32 MB of RAM". In what decade? My ISP provided router also does VPN, VoIP, mesh networking, firewalling, and it's towards the lower end of feature set (as it's offered for free and…

My TP-Link MR3020 from around 2015 only has 4^H 16 MB of ram (4 MB flash) and thus cannot even run OpenWRT anymore.

That thing was overstaying it's welcome for two years even then by staying on WiFi 4. 802.11n was adopted 15 years ago.

Re: Why systemd is a problem for embedded Linux

#227

Earlier quoted context omitted.

2015 was also almost 10 years ago.

So i guess its a brick now and there is nothing we can do about it.

Using something that's already been produced (good) is not the same as selling dead end e-waste that's so underspecced it's barely working new (bad).

Re: Why systemd is a problem for embedded Linux

#228

Earlier quoted context omitted.

My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended, and unexplained/unexplainable changes to the order of boot of some components. For the former I have given up playing whackamole with all the timeouts you need to reconfigure, for the latter I didn't even try because I know that there's something peculiar about my setup that will never wor…

> now I have to avoid that and minimise tinkering/hacking. I think this right here hits at the crux of the issue. There are people who like systemd because it's integration-tested with itself and its own defaults, so if you never change those defaults you don't have many problems. Then there are people who don't like systemd because if you do have to change any of its defaults, it often doesn't go well. And, of cours…

"See Figure 1".

Re: Why systemd is a problem for embedded Linux

#229
post #194

Earlier quoted context omitted.

You have been living in a strange world if you’ve been getting away with 1GB in the average consumer IoT device for the past 5 years. That’s not typical at all. I’ve done a lot of work with production runs in the millions. There is no way we’d put that much RAM on a device unless it was absolutely, undeniably required for core functionality.

Typically in IoT you'll count RAM in kB not MB and definitely not GB. See STM32 H5/H7/L4/L4+/U0 as an example.

Typically in IoT you'll use an soc that actually supported some kind of network connection

Re: Why systemd is a problem for embedded Linux

#230
post #74

Earlier quoted context omitted.

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

Ubuntu is literally trying to replace it with dracut as we speak.
Post reply on HN