3 ms·
Well, in most (older) init systems, boot scripts were shell scripts and you could do anything if you knew how, including shooting yourself in the foot. Great fl
by wvh 10y ago
Well, in most (older) init systems, boot scripts were shell scripts and you could do anything if you knew how, including shooting yourself in the foot. Great flexibility, great responsibility.
In systemd, services are described in a simple file with a few keywords, and systemd tries to do all the magic itself, in a way replacing the scripting part and all the possible code paths that could be gotten that way.
So if something in the system's boot or a process' start-up procedure doesn't work now, it's systemd's fault and not yours or whoever wrote the shell scripts in other init systems; and if the simple configuration file is not complex enough to do something you could do easily with a shell script, than it's also systemd's fault for being too simple.
I'm an old-timer and I like shell scripting, but also think systemd makes writing service files easier and has benefits such as built-in support for cgroups, security features (user/group, chroot, ...) and mini-services like basic ntp server. There were some bugs when distributions started to include it by default some years back, but I haven't had any problems lately.
- makomk 10y agoOne of the problems with systemd seems to be that it makes init scripts look simpler by spreading their complexity across multiple files all over the filesystem instead. The unit file systemd proponents were showing off as an example a few years back certainly looked simple compared to the init script it replaced... until you realise that its functionality had actually been split across several unit files and a bunch of shell scripts that they called. Look at this article and just count number of moving parts involved in getting NFS working with systemd too. Multiple service, target and socket unit files with the same name but subtly different behaviour, multi-hundred-line shell scripts in a directory most people won't even realise exists modifying some of them at runtime, ... In non-systemd init systems that'd all probably be one init script, and the fact that it was all in one place would sure make it look more complex.
- ChoHag 10y ago> In systemd, services are described in a simple file with a few keywords, and systemd tries to do all the magic itself So rather than building the necessary complexity out of simple, understandable instructions which can be presented on-screen in full, it hides its complexity under a very few complex, frequently badly-named instructions which are certain to be poorly documented even for Linux's standards. Sign me up! I'll be unfirable!