On unix systems, PID 1 is special. Orphaned processes (including a special case: daemons which orphan themselves) get reparented to PID 1. There are also some special signal semantics with respect to PID 1, and perhaps most importantly, if PID 1 crashes or exits, the whole system goes down (kernel panic).
Among the reasons systemd wants/needs to run as PID 1 is getting parenthood of badly-behaved daemons that orphan themselves, preventing their immediate parent from knowing their PID to signal or wait on them.
Unfortunately, it also gets the other properties, including bringing down the whole system when it crashes. This matters because systemd is complex. A lot more complex than traditional init systems. When I say complex, I don't mean in a lines-of-code sense. I mean in terms of the possible inputs and code paths that may be activated at runtime. While legacy init systems basically deal with no inputs except SIGCHLD from orphaned processes exiting and manual runlevel changes performed by the administrator, systemd deals with all sorts of inputs, including device insertion and removal, changes to mount points and watched points in the filesystem, and even a public DBus-based API. These in turn entail resource allocation, file parsing, message parsing, string handling, and so on. This brings us to:
On a hardened system without systemd, you have at most one root-privileged process with any exposed surface: sshd. Everything else is either running as unprivileged users or does not have any channel for providing it input except local input from root. Using systemd then more than doubles the attack surface.
This increased and unreasonable risk is not inherent to systemd's goal of fixing legacy init. However it is inherent to the systemd design philosophy of putting everything into the init process.
Luke Martin
Systemd is not an init system!! If someone characterizes systemd as an “init system,” you may safely assume that s/he is either utterly clueless or deliberately obfuscating the discussion. Calling systemd an init system is like calling an automobile a cup holder. Not even Lennart Poettering pretends that systemd is anything but the “Core OS” (sic).
What systemd is is an effort to re-create large portions of existing userspace (including login, job scheduling, and networking, just to name a few) inside a single process traditionally reserved for the sole purpose of starting *nix userspace. (Just in case it isn't clear, there is a huge difference between starting userspace (init) and being userspace (systemd).)
At the end of the day, how one perceives this re-creation of existing userspace strongly influences one's reaction to systemd. There are plenty of perfectly legitimate reasons to be troubled by this re-invention of the wheel; they range from the philosophical and aesthetic, to the technical and mechanical, even the purely political and brutally practical.
And that's part of the problem when folks start to “debate” systemd. Very few folks have the chops to think about, much less talk about all of these areas simultaneously. As a result, the discussion becomes fractured and disjointed, in what is literally the textbook definition of bikeshedding. Suddenly, a talking head who's never written a line of code in his/her life offers up an authoritative-sounding-but-utterly-bogus opinion on systemd's maintainability. Add in the fact that folks on both sides (including Poettering himself) act as if name-calling is a perfectly good substitute for empirical evidence, and the “debate” becomes indistinguishable from white noise.
>My problem with this is that the order in which services are started should, in my opinion, be exactly the same each time and predictable to the sysadmin. With systemd, the order is not deterministic, so you don’t know what’s going to happen next time you boot. I work with servers and embedded devices; I don’t care much about boot time. A server spends several minutes in the BIOS during POST anyway, before the bootloader is even run; making the OS boot faster doesn’t change very much. Embedded devices already start quickly because you trim them down to the bare minimum. What I care about is that every time I boot, the same exact things happen in the same exact order — the order that I want.
>It seems no one can agree on whether systemd is modular or not. I think the problem is with different definitions of ‘modularity’. Systemd doesn’t put everything in PID 1 like some people suggest; it uses modules that communicate with each other. So it is modular in that sense. But these modules are very tightly integrated. You can’t easy remove some of them, or replace them with other things. So in that sense it is very monolithic. This is not at all like having a simple interface and passing data via stdin and stdout, which is the modularity that makes UNIX pipes possible. This is the sense that matters to me.
>[...]I dislike the way systemd is absorbing everything. It’s not just an init system, it’s become an everything-under-the-hood includes-the-kitchen-sink management system. That doesn’t feel modular to me. Why should systemd implement NTP when ntpd already exists? I think systemd-timesyncd and all the others like it are just reinventing the wheel.
>Systemd is an exploit kit just waiting to be activated. And once it is active, only those who wrote it will be able to defuse it — and check whether it is defused. And it is starting: How to crash systemd in one tweet? Alternatives? Use OpenRC for system services. That’s simple and fast and full-featured with minimal fuss. Use runit for process supervision of user-services and system-services alike.
Anyone who isn't already sold on systemd being cancer is beyond help. Creating threads like this is like trying to use logic to talk people out of religion.
Austin Diaz
...
Gabriel Allen
How does it affect my daily usage of Linux as a workstation and a home computer?
Adam Bell
backdoors, reboot (like windows) to update system, etc
Austin Reed
Maybe you fucks should all flock to PCLinuxOS, or Void for you arch autists.
Elijah Jones
didn't know poettering was trans it all makes sense now
Lincoln Clark
I dont know I never cared about systemd until one day no hostnames were resolving for some reason. I check resolv.conf and it has some shit about systemd-resolved and 127.0.0.53? So I disabled it and set my nameservers back to normal and everything works as usual.
wtf is this shit? I cant understand why they would do this.
Caleb Williams
>PCLinuxOS If they remove nvidia and amd bloatware.. also they need to remove some other bloatware stuff
Alexander Walker
>logind moves every process started by the user into a cgroup >which is killed when they log out >including tmux or screen or anything like that
Void is fucking awful especially compared to Arch. The repo is small, there is no AUR, and the package system is in no way more capable than pacman yet at least 10 times more complicated.
Austin Smith
systemd has 6 million lines source code (and 1 million lines of other code) that is constantly changing and has never been audited. This thing has NSA written all over it.
Ryder Anderson
Anyone not using OpenRC by now is considered a proper idiot
