4 ms·
But those inits don't actually DO hardly anything. The Rust one hardcodes a bunch of stuff and has "TODO - setup signal handler" in the code... You're not even
by ragnese 6y ago
But those inits don't actually DO hardly anything. The Rust one hardcodes a bunch of stuff and has "TODO - setup signal handler" in the code...
You're not even comparing them to just the init part of systemd, but the entire repository.
What's the point here?
- drran 6y agoThe 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.