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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
