On Mon, Dec 19, 2016 at 10:19 AM, Alan McKinnon <[email protected]> wrote: > The truth is, as designs > go, sysvinit is a /terrible/ design. It only lasted 30 years because it > forces all the tricky bits to be someone else's problem >
I'm not sure I'd go as far as saying "terrible" - it does what it does reasonably well. I just doesn't do much. When people compare "systemd vs sysvinit" they're usually comparing systemd vs some other service manager, since all sysvinit does on 99% of installations is spawn some gettys and run the service manager. One of the things that is obviously missing from sysvinit is the ability to make non-persistent runtime changes. You can tell it to re-read inittab, but you can't say "please spawn 1 more getty, but don't do that next boot." The closest you could get to that is modifying inittab, refreshing init, then restoring inittab and not refreshing init. Systemd makes gettys just an instanced service, and you can of course start/stop those at will. I believe you can also feed systemd a unit without actually putting it on disk anywhere, though I'd need to double-check that. Since it uses D-Bus there is a lot you can do with it via IPC, and in fact that is how the various helper programs actually work. -- Rich
