Recent Features
| |||||||||||||
GNOME and/or systemdGNOME and/or systemdPosted Nov 4, 2012 1:16 UTC (Sun) by rleigh (subscriber, #14622)In reply to: GNOME and/or systemd by Cyberax Parent article: GNOME and/or systemd
This really isn't about "init vs systemd", it's about the complexity and robustness of PID1, whatever the init system in use might be.
There is a difference between the reliability of PID1 (e.g. /sbin/init) and the reliability of the programs run by that init such as rc (/etc/init.d/rc) for runlevel change, getty, and then e.g. individual init scripts run by rc/startpar.
In the case of sysvinit, init itself is small, simple and robust. It does little more than run rc on runlevel change, respawn gettys and handle a few other events such as shutdown signals. There is nothing stopping systemd, or a systemd-like complex init running as a respawnable service run directly from init (like getty), layering the more complex stuff on top of an ultra-simple PID1. This is partly what openrc does, building a more complex dependency-based boot on top of sysvinit.
The point here is that a bug in rc or getty will not kill init. And a bug in an init script will not kill rc. PID1 will carry on running, as will your system, if there is a bug in one of these higher level layers. Even in the case of sysvinit, there is scope to strip down PID1 even further--the runlevel change and service respawning could be moved into a separate process, as could shutdown.
While systemd does split some still out into additional binaries, the chance of a bug compromising PID1 functioning is much, much higher. Upstart is in a similar situation. Neither of these /need/ to have the complexity directly in PID1.
(Log in to post comments)
GNOME and/or systemd Posted Nov 4, 2012 1:33 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, in this case the sysvinit PID1 is !@#*&^!*& unreliable. It can't even kill processes robustly. It can't start them robustly as well - I've had more than one hangup during startup.
> The point here is that a bug in rc or getty will not kill init. And a bug in an init script will not kill rc. PID1 will carry on running, as will your system, if there is a bug in one of these higher level layers.
What use in a robust PID1 if it can't do ANYTHING reliably?
GNOME and/or systemd Posted Nov 4, 2012 12:27 UTC (Sun) by nix (subscriber, #2304) [Link] Well, in this case the sysvinit PID1 is !@#*&^!*& unreliable. It can't even kill processes robustly. It can't start them robustly as well - I've had more than one hangup during startup.You seem to misunderstand what I want of PID 1. Its job is to run an rc script when (in effect) the system starts up and shuts down and to reap processes. *Nothing else* (even forking gettys is really something else's job). Killing processes is killall's job. Monitoring processes is something else's job. Starting processes without hanging up is the job of some scripty thing or something. It is very definitely *not* the job of PID 1, since that is complexity that *can* be somewhere else, and thus *should* be somewhere else, rather than in the one process in the system whose death causes an instant kernel panic. You keep on giving complaints about sysvinit that have nothing to do with PID 1 robustness, which is my primary concern when choosing an init implementation. sysvinit never fails to reap zombies: it never fails to run its single rc script per runlevel change (those scripts might later hang, but that is not PID 1's fault). It never, ever dies. I would be happy with systemd were its PID 1 incredibly simple and never changing and all the work done by something else (which can change as often as it likes without causing instant kernel panics if it goes wrong). But instead its PID 1 is more of a kitchen sink than I'd like. Even sysvinit PID 1 really does too much: I'm definitely going to have a look at s6 and see if it has moved things like process supervision to some other binary. PID 1 should not do this job.
GNOME and/or systemd Posted Nov 4, 2012 17:25 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
If you limit systemd to only running SysV scripts then systemd is incredibly stable. I don't think there was a bug in sysv-compat for a long, long time.
Yet it makes absolutely NO sense to view PID1 functionality in itself. It can't do anything, and any script it runs becomes mission-critical. It's easy to make a non-bootable (or non-haltable) system by making a small mistake in a myriad of twisty [not so] little scripts. And it makes no freaking sense that PID1 itself worked fine.
A car analogy: sysv is a metal cube with thick metal walls. It's very safe (since it can't move) and simple. Only to make it actually do anything useful you need to add wheels, engine, steering system, windows and windshields, etc. And in the end it turns out that a cube on wheels actually doesn't really work as a car and isn't safe anymore.
|
|||||||||||||