Notes on how systemd's job engine is structured and other related bits
bl33pbl0p.github.io
bl33pbl0p.github.io
But then there's all the other crap that systemd's developers cling to religiously that hold back both the project and the development of complementary software. Their single-minded obsession over total control of a system, and having everyone (even kernel developers) bend to any crazy idea they have, resulted in a bad relationship with both users and developers. I don't think people hate systemd as much as how it was forced down their throats.
The really funny thing is how it's now basically just an overcomplicated init script. You don't use systemd in anything resembling modern service architectures (cloud-based, decentralized, etc) except to start some other tool that actually deals with those things.
That's probably the better way to express what I was trying to say. It seems really complex and rigid (and probably brittle?) for a script that's used basically to start services, but I may be missing something since I don't use Linux much and only then usually on a spare laptop. And as Theo once said, the process of booting an operating system is non-trivial. (Or words to that effect.)
Services are a common feature of modern operating systems. You have a dependency graph, you start something based on it, you either watch the process or wait for one to die, you reap it, you figure out what to do next (which is usually "restart the things I need to keep that thing running" or "die and warn the admin").
All of that is useful for daemons, things that need to keep running. For 99% of the rest of system booting, it's one-shot loading of stuff. So, many people (myself included) like just having a shell script to keep all that in, as one a system is built, the boot-up rarely changes. By keeping booting and a service manager separate, you can change things out as you wish.
You can do that easily if all pid 1 does is kick off the boot-time stuff, which itself kicks off the service manager. You can't do that if the service manager is the boot manager and both are pid 1. Or at least, now you need to kick off a second service manager from the first one and pretend the first one doesn't exist, which is non-trivial. The more responsibilities you take over, the more crap you need to support.
So as a result, systemd is an entire kitchen sink, because it needs to be for you to get anything done, due to its design decisions. With a different design they could offer any functionality and you could pick and choose what to use, but from what I understand now it's more like you have no choice.
That's actually few people, rather than many people, as the history of the past 40 years shows.
The simple fact of the matter is that after a system is built system administrators find themselves installing and uninstalling third-party applications softwares. Editing /etc/rc became tedious and error-prone, especially when installation/deinstallation utilities tried to do it automatically.
First there came /etc/rc.local in the late 1970s and early 1980s, where administrators could in theory cordon off the non-operating-system stuff for these applications, so accidents didn't wipe out half of /etc/rc any more. Problematically, value-added resellers thought that /etc/rc.local was their domain and put their stuff into it. One 1991 Usenix paper bemoaned the consequence of this that "there is no place to put 'real' local modifications and keep them distinct and separate from vendor supplied files".
Then came the idea in the early 1980s of drop-in shell scripts that could belong to individual softwares without need for editing a single monolithic shell script at all, the rc system of AT&T Unix System 3/System 5. This idea was repeated several more times. Miquel van Smoorenburg copied it for Minix and then Linux with an /etc/init.d/ directory. FreeBSD had a similar system by 1995 with an /etc/rc.local.d/ directory. Luke Mewburn reinvented it slightly differently for NetBSD in 2000 with an /etc/rc.d/ directory. Roy Marples reinvented it as OpenRC in 2007 with an /etc/conf.d/ directory.
All of this tells us that many people (not including you) in practice do not like the problems of just having a single shell script, and continually move away from it. Time and again over a period of 4 decades.
I have used a lot of Linux distros from Yggdrasil onwards via say Mandrake. My first kernel was 0.something. Back then we only had Miguel's method for init scripts. (I think). I use Debian, Redhat, Ubuntu, Arch, Gentoo, Centos and others at least these days. I now have only one initscript language to worry about.
gerdesj is specifically referring to the well-known problem that the helper utilities and functions for rc scripts varied wildly from operating system to operating system.
It's worth noting that the Debian people introduced another set of conventions recently, in 2014, with rc scripts in the Debian variant of the van Smoorenburg system now interpreted by a /lib/init/init-d-script command instead of a shell.
* http://jdebp.eu./FGA/system-5-rc-problems.html
Times have changed. My laptop that travels around a bit with funky VPN and proxy requirements is not the same beast as my desktop or server of years ago. Random bits of hardware get stuffed into it and pulled out with scant regard for common decency.
systemd is without doubt a bit odd in places (I'm a Brit and have experience of odd) but it provides a pretty decent approach to a PID 1 experience in the modern dynamic world.
Every time I come across a new "strange" issue in some server distro these days it's almost always systemd related - and usually something utterly insane.
Well, maybe I'll be more optimistic when we replace pulse audio for a start.
It may well be possible for there to be better general solutions to these problems, but systemd has been the best for my use cases (laptop, desktop workstation, server, headless embedded) each time I've evaluated anything else.
Are there problems? Probably (I haven't noticed, mind you); should they be addressed? Yes, certainly; Do problems people see in systemd mean that the whole thing is doomed and should be replaced with some unknown contender? I don't really think so.
If there were a better init system, an easier reliable NTP, better integration with Linux device events, more useful logging, simpler dhcp, etc. etc. etc. I would be using them (whether they were separate or integrated).
For me, it makes a huge amount of sense to enable ntp with timedatectl (assuming the upstream NTP is configured properly), to boot with systemd-boot† (formerly gummiboot), and to configure my simple networks with systemd-networkd. I have never needed to fuss with these things to get the essential benefit they claim to provide; and it has never been more convenient.
If I were starting a distribution today for anything except self-initializing applications or tiny microcontrollers, systemd would be the obvious choice, including most of its components.
† This is going to get even better and more universal as the ARMv8 ecosystem, and the RISC-V ecosystem inevitably continue to rally around UEFI. As far as I can tell, a universal distro installer for IA32, AMD64, AArch64, ARMv7, and every common Linux-capable (within reason, not counting μClinux here) RISC-V ABI is not actually going to be that crazy to make (apart from size restrictions on the install disk maybe) in a couple years.
I'm not quite sure what you're referring to here. OpenBSD just keeps getting cleaner and simpler to manage, but I'll admit that maybe I've just gotten more familiar with it over the years. There's definitely nothing like systemd lurking in there, though.
That's not separated.
Process can't fork?
Better check
* sysctl and /etc/sysctl.conf
* ulimit (soft and hard) and /etc/security/limits.conf
* systemd configuration, would could be in /etc/systemd/system, /run/systemd/system, /usr/lib/systemd/system, /usr/local/lib/systemd/system, or a half dozen other places
This isn't across a bunch of distros; this is all on the same Linux system.
And I guarantee this list isn't even complete.
Somebody is loving recreating what already exists.
`systemctl status blah.service` will tell you all the systemd unit files that configure the service, and `systemctl show blah.service` will show you the final config that is actually applied.