3 ms·

> Breaking this would basically break compatibility with every existing userland By "Breaking this" you mean "fixing the fact that pid 1 can't crash and restar

> Breaking this would basically break compatibility with every existing userland By "Breaking this" you mean "fixing the fact that pid 1 can't crash and restart"? > Because of this, it is better to fail hard It can't be fixed because it would "break compatibility" where that "compatibility" is that the machine should panic? You're not really making a good case for why this can't be changed. Why not * pid 1 exits * kernel re-executes init as a new pid 1 * userspace continues on as if nothing happened.

geofft 10y ago
Right. If init opts into it, e.g. by setting some sysctl or something, the kernel changes behavior in the following way: 1. Processes that are reparented to init aren't actually considered children of init for the purposes of the wait() system call. Their ppid still becomes 1, so parent process walks work, but when they exit, the kernel immediately cleans them up. Zombies still exist in this change, as long as their parent still exists; the only thing that changes is that processes (zombies or not) are not reparented to init when their parent dies. Direct children of pid 1 are not treated specially. 2. When init is about to exit or crash, the kernel turns it into a zombie. It then starts a new init process and reparents the old init to the new one, allowing it to do things depending on the cause of the crash. Direct children of the old init have lost their parent, and are treated like any other parentless process as described above. 3. If execing the new init fails, the kernel panics. This would be completely backwards-compatible. (I might even argue against 3, to remove all worry about init crashing; since pid 1 is no longer required to do anything, if exec fails, the kernel can just leave pid 1 as a stuck process table entry, let the system continue running, and log something to dmesg so the sysadmin can diagnose the problem and reboot the machine cleanly.)
- justinsaccount 10y ago
  Sounds reasonable. Any ideas why no one has ever done this? Kind of reminds me when the behavior of rm -rf / was changed in solaris. I can't find the article, but basically someone pointed out that they couldn't change the behavior of rm -rf / because posix defined how it should work. Someone then pointed out that the spec says that trying to remove the parent directory(i think?) should fail, and since rm -rf / includes removing the parent directory, it was within the spec that it should fail.

geofft 10y ago

Right. If init opts into it, e.g. by setting some sysctl or something, the kernel changes behavior in the following way: 1. Processes that are reparented to init aren't actually considered children of init for the purposes of the wait() system call. Their ppid still becomes 1, so parent process walks work, but when they exit, the kernel immediately cleans them up. Zombies still exist in this change, as long as their parent still exists; the only thing that changes is that processes (zombies or not) are not reparented to init when their parent dies. Direct children of pid 1 are not treated specially. 2. When init is about to exit or crash, the kernel turns it into a zombie. It then starts a new init process and reparents the old init to the new one, allowing it to do things depending on the cause of the crash. Direct children of the old init have lost their parent, and are treated like any other parentless process as described above. 3. If execing the new init fails, the kernel panics. This would be completely backwards-compatible. (I might even argue against 3, to remove all worry about init crashing; since pid 1 is no longer required to do anything, if exec fails, the kernel can just leave pid 1 as a stuck process table entry, let the system continue running, and log something to dmesg so the sysadmin can diagnose the problem and reboot the machine cleanly.)

justinsaccount 10y ago
Sounds reasonable. Any ideas why no one has ever done this? Kind of reminds me when the behavior of rm -rf / was changed in solaris. I can't find the article, but basically someone pointed out that they couldn't change the behavior of rm -rf / because posix defined how it should work. Someone then pointed out that the spec says that trying to remove the parent directory(i think?) should fail, and since rm -rf / includes removing the parent directory, it was within the spec that it should fail.