Comment 30 for bug 672177

On Tue, 2010-12-28 at 14:22 +0000, Scott James Remnant wrote:
> On Tue, Dec 28, 2010 at 6:47 AM, Clint Byrum <email address hidden> wrote:
>
> > This makes sense, because telinit u just sends SIGTERM to upstart, which
> > has no handler, as it was removed by revision 977, and doesn't seem to
> > have been added back. Since SIG_DFL signals are not delivered to init,
> > I'm not sure how umountroot's call to 'telinit u' can help in this case.
> >
> > Unless I'm missing something in upstart's code (quite likely) I think
> > there may still potentially need to be a change in upstart to support
> > re-executing.
> >
> Hmm, while that handled was removed Upstream, the code should have
> been retained in the Ubuntu package as part of the "telinit u" patch.
>
> The idea is that rather than doing a full state transfer, Upstart just
> re-exec's itself and loses all state. That's why we do it as the last
> thing before unmounting the root on shutdown, because it then doesn't
> matter about the state - there shouldn't be any.
>
> Maybe that part of the patch has been lost?
>

Ahh, as I suspected I was missing something in upstart's code.

That code is cleverly hidden within the package diff.

It registers nih_main_term_signal() which calls nih_main_loop_exit(),
which tells init to exit after any currently running operation is over.

So, it would seem init exits on SIGTERM. I did see it actually exit and
end up panicing the kernel once, but only when I sent multiple kills.

init should never exit, so should'nt we instead be execcing ourselves
again? Will keep digging in, maybe neither are happening as we expect
them to, causing this issue.