3 ms·
The initd job IS to launch other processes and reap zombies. (To non-technical people: zombies are childs which died when their parent is already dead, so a dae
by drran 6y ago
The initd job IS to launch other processes and reap zombies. (To non-technical people: zombies are childs which died when their parent is already dead, so a daemon must collect their souls).
It's not a job of init daemon to manage containers or resolve DNS names.
IMHO, systemd must be PID 2+, not PID 1.
- rcxdude 6y ago> The initd job IS to launch other processes and reap zombies. (To non-technical people: zombies are childs which died when their parent is already dead, so a daemon must collect their souls). Well, those initds don't actually start processes, they start one other process. > It's not a job of init daemon to manage containers or resolve DNS names. systemd's init doesn't do these things, other parts of systemd do that. > IMHO, systemd must be PID 2+, not PID 1. It is, for the most part (certainly most of those '1 million lines of code' are not in PID 1). Certainly you could try to keep more of the service management code out of PID 1, but it's honestly not something with huge practical benefits (your service management is going to be priviledged anyway, in the event of a crash all a non-PID 1 solution allows is maybe a little bit of an easier time giving a chance to inspect the wreckage before you need to restart everything anyway), and you create more interfaces in your system to manage.