1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code.

2. Speaking of kernel code, have you looked at how much stuff is going on in the kernel? Why does pid 1 get this much scrutiny, but the kernel, which definitely can't die, gets a free pass? On my system there are 77 kernel threads. Seventy-seven! What are they all doing??

And there are plenty of alternative kernels you can use. Multiple ones even have Linux binary compatibility.

3. Is the argument for suckless init the same as that for EWONTFIX init (on which it is based)? If so, would a fork of systemd that split it into two processes, PID 1 that reaps reparented zombies and tells PID 2 about it (over a one-way pipe, so PID 1 has no increased attack surface), be an acceptable option?

For point 2, I think you can use:

  ps -eLf | grep '\['

I put in a grep root for good measure:

  ps -eLf | grep '\[' | grep root

Incidentally, why would a zombie process need to be reparented? Surely it has just not been removed from the process table and all that needs to occur is to remove it fully... I can understand reparenting an orphan process, but a zombie process?

A ps roughly like that is how I got the number. That doesn't explain what they do. I'm sure I could dig into kernel sources, but... for instance, why am I running "xfsalloc", "xfs_mru_cache", and "xfslogd" when I have no XFS file systems?

The point I'm making is not so much that I'm curious (although I am), but that the kernel is exempt from the scrutiny that systemd gets, and the kernel has a ton of fragile crap running at full privilege. If systemd even shipped three XFS-specific binaries, people would be upset, but the kernel can run three persistent kernel threads and nobody cares.

You either have the xfs filesystem module loaded or compiled into your kernel.

I just tested this out:

  chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs
  chris@libreoffice-ia64:~$ sudo modprobe xfs
  [sudo] password for chris: 
  chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs
  root      6731     2  6731  0    1 16:53 ?        00:00:00 [xfsalloc]
  root      6736     2  6736  0    1 16:53 ?        00:00:00 [xfs_mru_cache]
  chris@libreoffice-ia64:~$ 
  chris@libreoffice-ia64:~$ sudo rmmod xfs
  chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs
  chris@libreoffice-ia64:~$

I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko.

My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general, about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are contributing to the existing efforts already in Debian to officially support alternative kernels.)

Ah, I'm following :-) I think perhaps the kernel is more esoteric than systemd, and as a team they have proven themselves over time. I think they get a fair amount of scrutiny from competitors (the BSDs, and Microsoft) and they have a very robust development process so that might explain why it's not as controversial.

The kernel also lives in kernel space, so unless one go micro-kernel, and dumps everything but the bare minimum into user space, a kernel will always be a big blob of code (most of it drivers, btw).

Ahem!

* https://news.ycombinator.com/item?id=8904429

* http://unix.stackexchange.com/a/197472/5132

Those StackExchange answers are awesome.

> functionality

That is, actually doing the work of init i.e. spawning daemons and services.

Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts.

It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.

Sure it does. Letting systemd handle startup dependencies is a very good thing, IMO. You configure some unit files to allow for one unit to start after another, otherwise they run in parallel. Not sure what the issue is with that?

As for those other tools... well, the systemd init process doesn't manage those either. The anciliary modules do, and quite well too really. I'm not entirely sure why people think that this is much different to running a SysV script to execute start a daemon!