3 ms·

> 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

> 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 the supporting cast of libraries. If you want to look at the true usage, check the RssAnon value: > root@kmipsrv:/proc/1# cat /proc/1/status | grep RssAnon > RssAnon: 3220 kB You can also pare this down a bit. Similarly for journald: > root@kmipsrv:/proc/1# cat /proc/231/status | grep RssAnon > RssAnon: 640 kB So in reality, systemd works just fine for the vast majority of embedded platforms. If you can spare 3Mb of RAM, then you can run a full-blown dependency management system with reliable recovery, logging integration, and event-driven device management. Soon with support for verified boot with hardware root-of-trust.

amelius 2y ago
This should be the top comment.
synergy20 2y ago
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.
- cyberax 2y ago
  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-powered-linux/ https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-...
  - simoncion 2y ago
    > OpenWRT should just stop being stubborn and integrate it. Why? If it fails to provide benefits commensurate to the effort required to integrate it, then there's no reason to do the work. OpenWRT is for routers and access points... devices which usually have a fixed [hardware] configuration, and very little need for the absurdly-complex (and in my professional experience, often subtly buggy) event-driven systems that systemd provides. "Every system everywhere gets to use the same unit files" isn't a significant benefit in practice... EVERYTHING that needs nontrivial pre-/post- start/stop verification and/or configuration has systemd run a shell script (or other such helper) anyway... so you only get to just write a unit file and call it a day in the most trivial of cases.
    - cyberax 2y ago
      OpenWRT is a mess. It started as a small distro for routers, but it stopped being that long ago. Now it can host telephony services, full-blown Docker orchestration systems, etc. So you get all the pleasures of complex systems running on antiquated infrastructure. > so you only get to just write a unit file and call it a day in the most trivial of cases. What "start/stop verification"? Give examples, please. Systemd natively supports device dependencies, network status, other services, etc. It's a very rare case when you _need_ shell in systemd.
      - simoncion 2y ago
        > Now it can host telephony services, full-blown Docker orchestration systems, etc. What features that systemd provides that aren't provided by openrc, runit, monit, openrc's init system, etc, etc, etc that are needed by software like Asterisk, Docker/runc, Kubernetes, and similar? If what OpenWRT is running works fine to bring that up, then systemd doesn't have any relevant compelling features that aren't provided by another init system. Switching away from something just because it's "antiquated" is a great resume-building tactic, but it's a pretty poor strategy when your objective is to keep things that have been working working with a minimum of effort. > What "start/stop verification"? Give examples, please. One example (out of many) are pre-start, pre-stop, and pre-restart configuration file correctness verification so that a typo or thinko doesn't bring a service down. A concrete example of this is Gentoo's running of 'named-checkconf' in BIND 9's service file [0]. Gentoo's BIND 9 systemd unit file [1] tries, but probably does not do the same thing... I don't know if 'ExecStartPre' runs before systemd brings down a service on a 'restart' action, but I bet you that it definitely does not run on service stop. I just checked and Ubuntu 22 does NOT do this sort of checking for its bind9 package, which is pretty wild. > It's a very rare case when you _need_ shell [or other such helpers] in systemd. Then you're either running "seatbelts off" (maybe without even knowing that you are), or you rarely deal with anything nontrivial. This need comes up a LOT in my day-to-day. [0] <https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/files/named.init-r15#n93 https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/...> [2] [1] <https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/files/named.service-r2 https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/...> [2] You might look at that file and be like "wow, TL;WR", but do try to notice how much of that file is dedicated to creating useful, human-readable status messages and error messages with good corrective instructions. If you care at all about your sysadmins, that complexity has to go somewhere, and that somewhere cannot be inside a systemd unit file... systemd just doesn't provide the features required to do that (and it would be kind of insane for the devs to even try).

amelius 2y ago

This should be the top comment.

synergy20 2y ago

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.

cyberax 2y ago
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-powered-linux/ https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-...
- simoncion 2y ago
  > OpenWRT should just stop being stubborn and integrate it. Why? If it fails to provide benefits commensurate to the effort required to integrate it, then there's no reason to do the work. OpenWRT is for routers and access points... devices which usually have a fixed [hardware] configuration, and very little need for the absurdly-complex (and in my professional experience, often subtly buggy) event-driven systems that systemd provides. "Every system everywhere gets to use the same unit files" isn't a significant benefit in practice... EVERYTHING that needs nontrivial pre-/post- start/stop verification and/or configuration has systemd run a shell script (or other such helper) anyway... so you only get to just write a unit file and call it a day in the most trivial of cases.
  - cyberax 2y ago
    OpenWRT is a mess. It started as a small distro for routers, but it stopped being that long ago. Now it can host telephony services, full-blown Docker orchestration systems, etc. So you get all the pleasures of complex systems running on antiquated infrastructure. > so you only get to just write a unit file and call it a day in the most trivial of cases. What "start/stop verification"? Give examples, please. Systemd natively supports device dependencies, network status, other services, etc. It's a very rare case when you _need_ shell in systemd.
    - simoncion 2y ago
      > Now it can host telephony services, full-blown Docker orchestration systems, etc. What features that systemd provides that aren't provided by openrc, runit, monit, openrc's init system, etc, etc, etc that are needed by software like Asterisk, Docker/runc, Kubernetes, and similar? If what OpenWRT is running works fine to bring that up, then systemd doesn't have any relevant compelling features that aren't provided by another init system. Switching away from something just because it's "antiquated" is a great resume-building tactic, but it's a pretty poor strategy when your objective is to keep things that have been working working with a minimum of effort. > What "start/stop verification"? Give examples, please. One example (out of many) are pre-start, pre-stop, and pre-restart configuration file correctness verification so that a typo or thinko doesn't bring a service down. A concrete example of this is Gentoo's running of 'named-checkconf' in BIND 9's service file [0]. Gentoo's BIND 9 systemd unit file [1] tries, but probably does not do the same thing... I don't know if 'ExecStartPre' runs before systemd brings down a service on a 'restart' action, but I bet you that it definitely does not run on service stop. I just checked and Ubuntu 22 does NOT do this sort of checking for its bind9 package, which is pretty wild. > It's a very rare case when you _need_ shell [or other such helpers] in systemd. Then you're either running "seatbelts off" (maybe without even knowing that you are), or you rarely deal with anything nontrivial. This need comes up a LOT in my day-to-day. [0] <https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/files/named.init-r15#n93 https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/...> [2] [1] <https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/files/named.service-r2 https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/...> [2] You might look at that file and be like "wow, TL;WR", but do try to notice how much of that file is dedicated to creating useful, human-readable status messages and error messages with good corrective instructions. If you care at all about your sysadmins, that complexity has to go somewhere, and that somewhere cannot be inside a systemd unit file... systemd just doesn't provide the features required to do that (and it would be kind of insane for the devs to even try).