CTRL-ALT-DEL not working as expected. Seeking for advices

[Laurent Bercot]

> You tell me truth about those distro startups. Therefore I striped that
> down to nothing! On my systems the kernel start a shell script from
> mine which does necessary initializations and then the scripts
> exec's my applications main, a very minimalist program, which does
> nearly nothing until it receives a signal. Based on the received signal
> it does exec another script of mine to shutdown the system.

 Eh, embedded systems are another thing - I think we all do something
like that, to some extent. But my point was that even for mainstream
distros, they could keep all the power, genericity and features of their
startup systems, and still move it into post-init, without having to
hide things in a useless pre-init phase.


> It is not only the sigmask issue. I noticed two things which may leed
> to a blocked signal situation. First is a sigmask blocking SIGINT and
> the second is SIGINT being ignored. And especially leads to trouble with
> Ctrl-C in the shell, as the shell does not enable SIGINT, if it is
> ignored on entry (feature not bug). So you need to check which issue
> is blocking your interrupt ... or you just unblock and restore all
> SIGs to there default action.

 Well, my tracking also applies to ignored signals. Right before init is
executed, there's no blocked signal. run-init does no signal work at all.
So, when the busybox shell executes into run-init, no signal is ignored.
If the busybox shell keeps the ignored signal list it receives on entry,
that means the kernel executes it with no signal ignored.
 But that specific point might very well have changed with recent kernels.
I see no reason why the kernel should have init ignore SIGINT by default,
as it totally defeats the purpose of /proc/sys/kernel/ctrl-alt-del
- but maybe the kernel guys managed to come up with one.


> ... it's a really simple wrapper to have as either /bin/sh or /bin/init
> to just do that signal unblocking than execve with the original
> arguments to /bin/busybox. This enables usage of a shell script as a
> long lived process 1 ... works since Linux kernel 2.2.1 on several of
> my Boxes without any failures.

 You mean, signal unblocking *and* unignoring, then.
 This is a safe option for sure. I doubt it's useful, but it can't hurt.


> A suggestion: Add that signal unblocking stuff to cttyhack.

 I support this suggestion.

-- 
 Laurent