Posted Nov 8, 2012 9:58 UTC (Thu) by michaeljt (subscriber, #39183)
Parent article: LCE: Systemd two years on
From the article:
"At this point, an audience member opined that the classical UNIX init process was designed to be as small and robust as possible, but that this seemed to contrast with where systemd was going. Is systemd at risk of becoming a large single point of failure? Lennart pointed out that while systemd replaces many earlier tools, it performs those tasks in separate processes. However, the notable difference is that the various components operate in a much more integrated fashion."
Which presumably only goes half-way to answering said audience member's question. Doing everything in separate processes should certainly make it easier to keep the init process small and robust, on condition that the overall process is well tested for how well it copes with failures of individual components. Does anyone know if that is being done?
Posted Nov 8, 2012 11:54 UTC (Thu) by zuki (subscriber, #41808)
[Link]
Those "individual components" are subject to the same rules as normal systemd units (e.g. daemons), in that their exit status is recorded and each component, after it finishes, has a status of Success or Failure. Other components have dependency rules, so if they are marked to require the first component, they will not be started if it fails.
If a basic boot-up "component" fails, e.g. fsck of the root filesystem, then the system bootup will be stopped and a login prompt will be opened for the admin to fix things. So in this regard this is similar to sysvinit, except that what is required and what is not for the basic boot is configurable.
LCE: Systemd two years on
Posted Nov 8, 2012 14:50 UTC (Thu) by michaeljt (subscriber, #39183)
[Link]