Init Dilemma

Init Dilemma

Yeah, I know the aged old fight that arises when systemVinit and systemd is at the table of any discussion. I’ve once been put in a situation where I had to make a difficult choice between which Init system was best for my embedded Linux development project.

I’m going to talk about this dilemma however old this argument might be. Which I think it’s best to put it out there for anyone that might come across this and get some interesting insights. Alright, alright maybe I’m talking too much, let dig right in.

Init program is the first process responsible for managing the lifecycle of the system from boot up to shutdown.
Working with embedded devices, there are three Init programs that you would probably come across :-
systemVinit
BusyBox Init
systemd

BusyBox Init:

For cases where you are creating your own embedded Linux image for your device, you might want to consider using BusyBox Init system as it has a very small Init program that uses a config file [/etc/inittab] to define steps to start programs at boot up and stop them at shutdown mode.
BusyBox makes it easy for you to write your own Init scripts, but this applies to small projects. Whereas embarking on complex projects, the Init scripts become unmaintainable. Hence it is advisable to automate the process by using open source tools like Buildroot or Yocto Project.
Talking about tools that automate the process; Buildroot uses BusyBox as it’s default Init program although Buildroot has options to build all three Init programs. Basically the BusyBox Init program is just a trimmed down version of systemVinit.

SystemVinit:

Compared to BusyBox Init, the boot scripts are written in a well-known modular format, making it easy to add new packages at build time or runtime.
SystemVinit has the concept of runlevels, which starts or stops a collection of daemons when switching from one runlevel to another. SystemVinit also start daemons in a specific order.
Yocto Project uses systemVinit as it’s default Init program although it has option to build with systemd.
Until recently systemVinit was the go to Init program for almost all server and desktop distributions including a fair number of embedded systems, I say fair number because in truth, runlevels are not used that much in embedded Linux as most devices simply boot to default runlevel and stay there.

Systemd:

Compared to systemVinit, has a faster boot time owing to the fact that many daemons services start in parallel making it easier for developers, because it’s no longer necessary to figure out the order in which the daemons should start.
Systemd has the concepts of runtargets, which does not necessarily stops a daemon (configurable) when switching from one runtarget to another.

Systemd has a lot of advantages, to list but a few:
- using systemd it is easy to control and setup your daemon’s execution environment.
-systemd provides better security features for your daemon.
- writing a bullet-proof startup script is hard, as your embedded system has to detect error or crash when there’s no admin. But with systemd, it makes sure your daemon starts, runs and shutdown correctly as it provides robust startup logic with timeouts, pre-start scripts, post-start scripts, robust cleanup, post-exit scripts.
- systemd provides software watchdog with a single API call to monitor your daemon, as watchdogs are a common requirement in embedded devices.
- systemd enables a configurable restart upon daemon crash, including grace periods and burst protection.
- systemd provides well defined dependency/ordering system, i.e you have a precise control over when or what order your daemons should start.

So in conclusion if you designing a simple system to launch very few daemons → BusyBox is sufficient, whereas for projects that involve resolving complex dependencies between services at boot time or runtime, then systemd would be the best choice.
However, considering storage space constraints, you might want to choose systemVinit, anyway the extra storage isn’t so much of a big deal because systemd had a lot of useful features. Be that as it may, I had no intentions to stir up heated conversations, nevertheless the comment section is an open floor. 😂️