[makomk]

No, your process supervisor crashing won't be as fatal as init crashing, because init crashing is an instant kernel panic under Linux. Also, very few projects are as robust as the Linux kernel or have development practices that are as good, and systemd is unlikely to be one of them.

[the_why_of_y]

When the supervisor crashes, which should occur extremely rarely in any case, the state of which services are running is lost, and its child processes are re-parented to PID1, so when a new instance of the supervisor starts it cannot tell which services are running, and which of the running processes belong to which service. During the time the supervisor needs to re-start (presumably init would respawn it?), some of the running processes could exit without notice.

What is gained by restarting then? You'll likely want to reboot to get the system into a consistent state anyway.

Here is a war story of an embedded developer who actually created his own init system with separate supervisor process, and found that it doesn't actually make the system as a whole more robust:

https://lwn.net/Articles/623527/

For a good disucssion of the trade-offs involved see this comment by JdeBP:

https://news.ycombinator.com/item?id=8384251

Edited to add: Also, is your comment about bad development practices in the systemd project purely based on statistical conjecture (which would mean it applies to every single project, except of course the Linux kernel where presumably you have personally observed the absence of bad practices), or do you have anything to back that up?

[digi_owl]

Lovely exchange in those LWN comments about monolithic vs modular. In particularly how the proponents are (perhaps willfully) confusing public and private APIs...