On Tue, May 05, 2015 at 12:29:59PM +0200, Jürgen Buchmüller wrote:
> Am Dienstag, den 05.05.2015, 11:22 +0200 schrieb Didier Kryn:
> > I'm not sure what happens if init crashes after other processes have
> > been started, wether the kernel panics or other processes continue
> > without init - not a very good situation.
>
> FWIW: I've seen this happening with a home grown jessie (RC2) for
> Cubietruck (armv7hf) where a module was seriously broken and led to a
> segfault.
>
> Since with systemd modules seem to be loaded by pid 1 itself, the crash
> takes down systemd with it and the system reboots after exiting pid 1,
> just crash again when trying to load the broken module the next time. No
> chance to break out of this loop AFAIK.
>
> To me this looks like a fundamental design flaw. A crashing module
> should never _ever_ take the whole system down. There has to be some
> privilege separation and signal handling in place to prevent that.
>
> With SysV init this is no big problem, as usually some child process of
> init (a shell script) loads the detected (udev rules) or defined
> (/etc/modules) modules and if it crashes, init will still be alive.

I presume "module" == "kernel module".
A module is never run in the same context as the process that loads it.
It is a part of the kernel, and thus runs in the kernel context.
If it crashes, it crashes the kernel or the associated device disappears.

By default, udev automatically loads non-blacklisted modules based
on the hardware it detects.
On a systemd-based system, udev is mandatory; it is not a part of pid 1,
though it is built from the systemd source.

If you can figure out what module is causing the crash, you can blacklist
it.

HTH,
Isaac Dunham