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