LCE: Systemd two years on

Bash isn't written in C, and you couldn't (for example, I haven't checked this) pull Bash's parser into another program, so that a legacy script could remain usable?

Having used systemd on an embedded project by now, I can say from experience that legacy init scripts can just as easily be called via a systemd config file aka "unit file" as they could via the base rc script. I don't remember having to modify the base rc script which iterates through all the scripts in the appropriate runlevel, and analogously I do not expect to have to modify the systemd parser which iterates through unit files to decide what services need to be kicked off.

sysvinit -> inittab -> rc script -> init.d scripts

systemd -> unit files -> init.d scripts

There is an option to stick the start/stop command lines directly in the unit files if they are single-liners, but if that is the case the main thing an admin might want to do is stick in a 'strace' or 'ltrace' of the daemon, and that can just as easily be done by editing the unit file as an init.d script.

The increasing list of dependencies for normal systemd operation on the other hand... can indeed be a pain for embedded projects. Even the requirement for cgroup support required a patch against the vendor-supplied kernel (yes many embedded Linux projects are *still* that out of date)

What kind of argument is that supposed to be? You don't need to modify systemd's C code to launch a shell script from a systemd unit. Just stick the script's name in the unit file's ExecStart line.

aiui, any *properly* *written* init script is 99% boilerplate, and 1% specific. Assuming just ten lines of specific code, that's a thousand lines of boilerplate :-)

systemd simply implements that 99% in small C procedures. The result is far less duplicate code, and far less opportunity for mistakes. Plus far greater testing, and hence solidity.

That one percent is still a text-editable script, just a systemd config file rather than bash code.

Cheers,
Wol