Demystifying Systemd for Embedded Systems – Gustavo Sverzut Barbieri, ProFUSION Embedded Systems

Systemd can be used for embedded systems. It can be made small and scale to what is needed.

Gustavo is interested in booting fast, he has implemented many (fast) boot/init systems for customers. He hacked many init systems before systemd existed; since it was public, he has used it.

In IoT, development cycles are extremely short. To make this possible, they use concepts like containers on embedded devices in the IoT frameworks. This makes manual fine-tuning not an option.

Proper babysitting of processes is not simple: double fork, PID files, …

Systems are dynamic. E.g. the network is not available all the time after running S40networking.

Ostro is an Intel project to create a yocto-based pre-compiled, pre-configured and pre-secure OS for IoT. Initially it supported both systemd and sysvinit, but that’s making things difficult for the rest of the distro. Stateless is important. They created their own configuration file format that is used to configure all services in a unified way.

For securing, isolation with namespaces is important.

Systemd for embedded myths

Dbus is not strictly needed: it’s only really used by systemctl, so if you don’t need dynamic control of systemd, you don’t need it.

Systemd is large: 18M on x86_64. But it contains dozens of tools, e.g. journalctl: great for a sysadmin, but maybe not needed on your embedded system. About 1MB (out of 3MB executables) debug tools like systemd-analyze. systemd binary itself is still 1.1MB however. udev accounts for 6.9MB, but 5.8MB out of these are hwdb. libnss_*.so name services plugins are really needed only for clouds.

By using configure –disable options and building with -Os, the x86_64 footprint goes down from 18MB to 7.4MB. Additional manual removing (libnss*, debug tools) goes down to 5.4MB. Removing journal (not advised) goes down to 5MB. Remove udev goes down to 3.9MB. But this still provides a lot of features beyond sysvinit, which sometimes replace other tools (cron, monit) or which are just needed (namespaces).

Conversely, if you want to scale up from busybox, you need additional packages, e.g. ifplugd, tmpcleaner, … . Also you need to do everything on your own, it doesn’t work out of the box.

If you want to go really small, you should make a PID1 that is statically linked and contains your application. Soletta Project anyway already implements system services like reboot on e.g. Zephyr, Contiki so reuse this API on Linux. It can also spawn processes (e.g. bluetoothd). It can make a fully functional PID1 with network and watchdog support, statically linked with musl into 400KB.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s