Debian reconsiders init-system diversity

Posted Nov 15, 2019 11:31 UTC (Fri) by tao (subscriber, #17563)
In reply to: Debian reconsiders init-system diversity by ncm
Parent article: Debian reconsiders init-system diversity

Code quality? Have you even looked at the content of a typical /etc/init.d? On my laptop which is rather barebone in terms of installed software there are no less than 17 scripts that have at least one call to sleep in them. 18 parses things with sed, 16 uses grep. All files look subtly different, all of them have tons of boilerplate code, at least 25 of them uses pidfiles, 10 of them calls some variant of kill, ...

And that's still with a distro with rather strict policies for everything.

Compare this to .service files. Simple dependencies, simple logging, simple rules for start/stop/restart etc.

There certainly are a few really complex .service files (timesync1 comes to mind), typically to lock things down. Most of such functionality cannot even be had from initscripts though.

So tell me again, what code quality issues do you see with systemd that sysvinit + a myriad of scripts doesn't suffer from?

Debian reconsiders init-system diversity

Posted Nov 26, 2019 12:02 UTC (Tue) by immibis (subscriber, #105511) [Link]

Code quality problems at lower layers are more serious. The shell scripts in /etc/init.d can, at least in principle, all be thrown away and rewritten. And if one crashes, it only affects that service. By contrast, the core of the system (any system) is relatively unchangeable and bugs have a greater impact.

FUSE drivers can afford to be far less stable than in-kernel filesystem drivers - now imagine importing that instability into the kernel without cleaning it up.