Hi, The Wanderer: > None of those things are done exclusively at boot / shutdown time, so > they should not be done by the init system. If they are done at all, > they should be done by something which can run and do them under any > init system. > The whole point of an init system is to start programs. Do you honestly want to implement all of this twice -- once for "real" startup+shutdown, and once for everything else? What do you do when the line between the two gets more and more blurry? > Because, since there is only one slot for PID 1 per system, having > something depend on a feature that is provided by PID 1 breaks choice. So if you want another init system, you implement that feature some other way. Which is exactly what the systemd-shim authors are doing. So what's the problem? > Note that I (think I) would have no objection to providing such features > both in PID 1 (for its own use) and in an init-system-independent > external process, with PID 1 providing them for use by other things only > if and as no external provider is available. I can think of a bunch of problems you'd have to solve for this idea to work. All of which just go away if you simply use the code in PID1. Which you need anyway. Which is why the systemd people decided not to do that. All this talk about generic $FEATUREs misses one crucial point: Exactly which feature of systemd-as-PID1 would one want to move to a separate process? And which second implementation would be a suitable replacement? -- -- Matthias Urlichs
Attachment:
signature.asc
Description: Digital signature