Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On Thu, Mar 21, 2013 at 12:18 AM, Bruno Cornec br...@victoria.frmug.org wrote: We have an opened bug report (Cf: http://trac.mondorescue.org/ticket/627) concerning the restoration phasebase don busybox, where a user is supposed to be able to press CTRL-ALT-DEL in order to reboot the computer before launching an automatic restore. This is not working as expected. We are up to now using version 1.18.5, with the attached .config file to compile busybox. We have an inittab file containing: # # inittab This file describes how the INIT process should set up # the system in the mindi-busybox context # # Order is important, read from bottom to top # By default launch the MondoRescue script console::sysinit:/etc/init.d/rcS console::restart:/sbin/init # Trap CTRL-ALT-DELETE null::ctrlaltdel:/sbin/reboot null::shutdown:/bin/killall klogd null::shutdown:/bin/killall syslogd null::shutdown:/bin/umount -a -r I'm testing mostly on KVM VMs, and simulate the CTRL-ALT-DEL with the sendkey command from the monitor window. This is working when we are at syslinux boot prompt, but as soon as we launch init, then we are unable to reboot the VM using CTRL-ALT-DEL. I also tested on real HW with the same result. So I'm surely doing something wrong, either in my inittab or in my congif of busybox, but I don't see what. I even tried with the latest 1.20.2 (which I may use as the base for the next stable version) without more luck either. Using showkey in the VM, I see that the sendkey command does indeed send the keys to the system, but it doesn't generate the reboot. I attached the corresponding capture. I read at http://lists.busybox.net/pipermail/busybox/2012-May/077855.html that a reason could be a non-busybox reboot but that's not our case. While we do replace some busybox commands by the native ones, reboot is linked to busybox (as well as halt, but not shutdown, which I just remarked now,but linking it to busybox doesn't change stuff anyway). So I'm looking for advises on how to debug more, or any hint wrt my usage. Pressing CTRL-ALT-DEL sends SIGINT signal to process 1. You want to make sure it reaches it. The handler is installed here in init.c: /* SIGINT (Ctrl-Alt-Del) must interrupt wait(), * setting handler without SA_RESTART flag. */ bb_signals_recursive_norestart((1 SIGINT), record_signo); You can write a my_record_signo() function which also prints signal number on stdout. Then, you may want to similarly check whether this location is reached in check_delayed_sigs(): if (sig == SIGINT) run_actions(CTRLALTDEL); -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi ! On 19-02-2014 14:31 Denys Vlasenko vda.li...@googlemail.com wrote: # Trap CTRL-ALT-DELETE null::ctrlaltdel:/sbin/reboot Pressing CTRL-ALT-DEL sends SIGINT signal to process 1. You want to make sure it reaches it. Don't forget to set /proc/sys/kernel/ctrl-alt-del to 0 (zero) to enable sending SIGINT to the init process. e.g.: echo 0 /proc/sys/kernel/ctrl-alt-del Without this most Linux kernel try an immediate reboot without saving buffers etc., know to fail/hang on some emulators. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On Wed, Feb 19, 2014 at 2:48 PM, Harald Becker ra...@gmx.de wrote: On 19-02-2014 14:31 Denys Vlasenko vda.li...@googlemail.com wrote: # Trap CTRL-ALT-DELETE null::ctrlaltdel:/sbin/reboot Pressing CTRL-ALT-DEL sends SIGINT signal to process 1. You want to make sure it reaches it. Don't forget to set /proc/sys/kernel/ctrl-alt-del to 0 (zero) to enable sending SIGINT to the init process. e.g.: echo 0 /proc/sys/kernel/ctrl-alt-del Without this most Linux kernel try an immediate reboot without saving buffers etc., know to fail/hang on some emulators. init.c does that already: /* Turn off rebooting via CTL-ALT-DEL - we get a * SIGINT on CAD so we can shut things down gracefully... */ reboot(RB_DISABLE_CAD); /* misnomer */ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Denys ! On 19-02-2014 15:35 Denys Vlasenko vda.li...@googlemail.com wrote: On Wed, Feb 19, 2014 at 2:48 PM, Harald Becker ra...@gmx.de wrote: On 19-02-2014 14:31 Denys Vlasenko vda.li...@googlemail.com wrote: # Trap CTRL-ALT-DELETE null::ctrlaltdel:/sbin/reboot Pressing CTRL-ALT-DEL sends SIGINT signal to process 1. You want to make sure it reaches it. Don't forget to set /proc/sys/kernel/ctrl-alt-del to 0 (zero) to enable sending SIGINT to the init process. e.g.: echo 0 /proc/sys/kernel/ctrl-alt-del Without this most Linux kernel try an immediate reboot without saving buffers etc., know to fail/hang on some emulators. init.c does that already: /* Turn off rebooting via CTL-ALT-DEL - we get a * SIGINT on CAD so we can shut things down gracefully... */ reboot(RB_DISABLE_CAD); /* misnomer */ Outch! ... if you do this before proc is mounted and system is prepared successfully, most emulators fail and many linux systems just hang when they receive a ctrl-alt-del. The command is right (same as writing to /proc/sys/kernel/ctrl-alt-del) but time to do this is wrong. Move that behind the initial system setup, then enable ctrl-alt-del. As I had several trouble with Busybox init, I dropped that and replaced it with my own programs, so I didn't note earlier the wrong time you enable ctrl-alt-del in BB init. I do not know what's the reason for this. I just found it necessary to enable ctrl-alt-del at the right time in system setup (and not earlier). Had several kinds of trouble on system startup, when ctrl-alt-del is enabled to early and one presses ctrl-alt-del. I did never look or try to analyze this. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On Wed, Feb 19, 2014 at 3:58 PM, Harald Becker ra...@gmx.de wrote:
Pressing CTRL-ALT-DEL sends SIGINT signal to process 1.
You want to make sure it reaches it.
Don't forget to set /proc/sys/kernel/ctrl-alt-del to 0 (zero)
to enable sending SIGINT to the init process.
e.g.: echo 0 /proc/sys/kernel/ctrl-alt-del
Without this most Linux kernel try an immediate reboot without
saving buffers etc., know to fail/hang on some emulators.
init.c does that already:
/* Turn off rebooting via CTL-ALT-DEL - we get a
* SIGINT on CAD so we can shut things down
gracefully... */ reboot(RB_DISABLE_CAD); /* misnomer */
Outch! ... if you do this before proc is mounted and system is
prepared successfully, most emulators fail and many linux systems
just hang when they receive a ctrl-alt-del.
No. Calling sys_reboot with RB_DISABLE_CAD nee
LINUX_REBOOT_CMD_CAD_OFF nee zero
results in this code executing in kernel:
case LINUX_REBOOT_CMD_CAD_OFF:
C_A_D = 0;
break;
which in turn has this effect on Ctrl-Alt-Del keypress:
void ctrl_alt_del(void)
{
static DECLARE_WORK(cad_work, deferred_cad);
if (C_A_D)
schedule_work(cad_work);
else
kill_cad_pid(SIGINT, 1);
}
- exactly what init wants.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Denys ! No. Calling sys_reboot with RB_DISABLE_CAD nee LINUX_REBOOT_CMD_CAD_OFF nee zero - exactly what init wants. Denys the problem is the time init does this call. When C-A-D is enabled to early (before complete system initialization) many systems fail badly and emulators tend to hang when you try C-A-D in the phase of system startup. Per intention enabling C-A-D shall only be done when system is up and init system is ready to process action on SIGINT, not earlier. Current init seem to enable C-A-D before executing sysinit actions. It shall be done AFTER sysinit not BEFORE. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On 03/29/2013 11:56 AM, Harald Becker wrote:
Hi Denys !
Hence my suggestion to add this sigprocmask to unblock all signals
*AND* restore all signal actions to there default as part of the
cttyhack applet.
I would like to hear people confirming that kernel indeed blocks
ant signals to pid 1. Which kernel version does that?
Linux 3.0.0 and 3.6.11 do not mask any signals.
And it's easy to find out!
/root # gcc init-debug.c
(see attached init-debug.c)
followed by editing grub's boot line during a reboot:
kernel (hd0,0)/vmlinuz-... root=/dev/sda2 init=/root/a.out
revealing
SigPnd:
ShdPnd:
SigBlk:
SigIgn:
SigCgt:
CapInh:
CapPrm:
CapEff:
CapBnd:
Meanwhile, the man page for kill (2) says:
The only signals that can be sent to process ID 1, the
init process, are those for which init has explicitly
installed signal handlers. This is done to assure the
system is not brought down accidentally.
So perhaps the confusion is that Linux is simply not delivering
the signal (regardless of sigprocmask) unless you install a signal
handler. I question whether anyone would actually want to write a
shell script with signal handling to act as init... that seems
messy and error prone.
Anyway, this little test also reveals that (as I thought I remembered)
you have to make a special syscall to get the ctrl-alt-del behavior.
Namely,
reboot(RB_DISABLE_CAD);
causes the system to stop instantly rebooting when ctrl-alt-del is
pressed, and instead send SIGINT to pid 1. I'm not even sure if
there is a command-line access to this call. I've only ever done
it from C.
setting on entrance. So the central place to trow that signal
unblocking/default action restoring is the place used to startup the
shell, usually the cttyhack applet.
- Restoring signal actions to there default and unblocking doesn't
harm if it's done without being required. It just waste some
time/code space, but avoids lengthy debug sessions due to blocked
signal handling.
Can you name any actual cases where busybox caused signals to be
blocked?
Again, I'm suspecting that the real problem all along was either a
missing call to reboot (2) or not installing a handler and causing
the kernel to not deliver the signal.
-Mike
#include stdio.h
#include sys/fcntl.h
#include sys/mount.h
#include string.h
#include signal.h
void sig_handler(int sig_num) {
fprintf(stderr, Caught signal %d\n, sig_num);
}
int main() {
char buf[4096];
int fd, got, i;
struct sigaction sa;
if (mount(proc, /proc, proc, 0, ) != 0)
perror(mount(proc));
if ((fd= open(/proc/1/status, O_RDONLY)) 0)
perror(read(/proc/1/status));
got= read(fd, buf, sizeof(buf));
sleep(5);
write(1, buf, got);
memset(sa, 0, sizeof(sa));
sa.sa_handler= sig_handler;
for (i=0; i64; i++)
if (sigaction(i, sa, NULL) 0)
fprintf(stderr, Can't listen to signal %d\n, i);
fprintf(stderr, Entering infinite loop\n);
while (1)
sleep(999);
}
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Linux 3.0.0 and 3.6.11 do not mask any signals. Neither do Linux 2.6.32 or 3.2.34, in my experience. kernel (hd0,0)/vmlinuz-... root=/dev/sda2 init=/root/a.out Depending on your kernel, it may be a little more complicated than that. If your kernel has been compiled with an initramfs, the first userland process won't be /root/a.out, but the /init file in the initramfs. If that /init file is a script, then the first userland process is the script interpreter. So perhaps the confusion is that Linux is simply not delivering the signal (regardless of sigprocmask) unless you install a signal handler. No, this is not the problem. Every shell in the world traps SIGINT. I question whether anyone would actually want to write a shell script with signal handling to act as init... that seems messy and error prone. Lots of people do that, and for good reasons: see http://skarnet.org/software/s6/s6-svscan-1.html For shell scripts, remember that process 1 is the shell itself, not the subprocesses, so no specific signal handling is needed. The shell performs enough signal handling by default. Anyway, this little test also reveals that (as I thought I remembered) you have to make a special syscall to get the ctrl-alt-del behavior. Namely, reboot(RB_DISABLE_CAD); causes the system to stop instantly rebooting when ctrl-alt-del is pressed, and instead send SIGINT to pid 1. I'm not even sure if there is a command-line access to this call. echo 0 /proc/sys/kernel/ctrl-alt-del -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Laurent Bercot wrote: kernel (hd0,0)/vmlinuz-... root=/dev/sda2 init=/root/a.out Depending on your kernel, it may be a little more complicated than that. If your kernel has been compiled with an initramfs, the first userland process won't be /root/a.out, but the /init file in the initramfs. The kernel is never compiled with an initramfs. The kernel is often compiled to use an initramfs, if the boot loader supplies one. If you don't load an initramfs (with the command initrd in grub), the kernel won't use one. The other question is whether the kernel has all necessary drivers compiled in to mount the root filesystem. But if the kernel mounts the root partition and starts the program when you don't pass an initrd parameter, you can be sure that this /root/a.out was started directly by the kernel. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On 03/30/2013 05:34 AM, Laurent Bercot wrote: So perhaps the confusion is that Linux is simply not delivering the signal (regardless of sigprocmask) unless you install a signal handler. No, this is not the problem. Every shell in the world traps SIGINT. Hm, true... but then the problem you actually have is that there might be signals that the shell is allowing to be delivered that you didn't expect. I question whether anyone would actually want to write a shell script with signal handling to act as init... that seems messy and error prone. Lots of people do that, and for good reasons: see http://skarnet.org/software/s6/s6-svscan-1.html You make great arguments for stage 1 and 3, but it still seems a shell is ill-suited for stage 2. You would have to handle any signal where you didn't want the shell's default behavior, and if I remember right, there was also a trick needed to get the shell to reap zombies. It just seems too easy to write a tiny C program that 1 - launches a supervisor 2 - reaps zombies 3 - runs a script when it receives signals 4 - execs stage 3 when the supervisor exits Not to mention the large number of supervisor programs that already do this. I use shells as init sometimes, but mostly just for diagnostics. I'm not even sure if there is a command-line access to this call. echo 0 /proc/sys/kernel/ctrl-alt-del Ah, nice. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On 03/30/2013 01:58 PM, Ralf Friedl wrote: The kernel is never compiled with an initramfs. The kernel is often compiled to use an initramfs, if the boot loader supplies one. Actually, check kconfig for newer kernels. They have an option to automatically create the cpio archive from a directory of your choice and build it directly into the kernel image. I used this for a while because it seemed convenient, but then decided I'd rather decouple the kernel from the initrd so I could mix match (and do things like init=/bin/sh). I imagine it makes life easier for people with limited bootloaders, or people making advanced use of kexec. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On 30 March 2013 19:45:09 Michael Conrad mcon...@intellitree.com wrote: On 03/30/2013 01:58 PM, Ralf Friedl wrote: The kernel is never compiled with an initramfs. The kernel is often compiled to use an initramfs, if the boot loader supplies one. Actually, check kconfig for newer kernels. They have an option to IIRC this was introduced pretty early in the 2.6 series, fwiw. Cheers, Sent with AquaMail for Android http://www.aqua-mail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
You make great arguments for stage 1 and 3, but it still seems a shell is ill-suited for stage 2. You would have to handle any signal where you didn't want the shell's default behavior, and if I remember right, there was also a trick needed to get the shell to reap zombies. Oh, I wasn't arguing about stage 2 at all. Having a shell as process 1 is either stage 1 or stage 3, or debug/recovery mode with an interactive shell, which causes the infamous job control turned off problem cttyhack is supposed to work around. I agree it is totally nonsensical to use a shell as a normal stage 2 process 1. It just seems too easy to write a tiny C program that 1 - launches a supervisor 2 - reaps zombies 3 - runs a script when it receives signals 4 - execs stage 3 when the supervisor exits Not to mention the large number of supervisor programs that already do this. runit does exactly that. s6-svscan also does that - except it is, strictly speaking, the supervisor. Process 1 management is a solved problem, has been for a while now, and that's why I can rant on and on about it when presented with less-than-optimal (to remain civil) solutions. ;) SysVinit being one of them. systemd being another. We've strayed far away from the OP's question, and I'm afraid I'm the main culprit. My apologies. Denys' answer looks promising to me, however - much more promising that the kernel starts init with a nonempty sigmask hypothesis, which I've only been able to find evidence against. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On Sat, Mar 23, 2013 at 12:53 AM, Bruno Cornec br...@victoria.frmug.org wrote: We are up to now using version 1.18.5, with the attached .config file to compile busybox. We have an inittab file containing: ... # Trap CTRL-ALT-DELETE null::ctrlaltdel:/sbin/reboot Try removing null. Init actions fail if opening of the tty fails. Empty tty won't try opening anything, will reuse init's stdio: ::ctrlaltdel:/sbin/reboot I'm testing mostly on KVM VMs, and simulate the CTRL-ALT-DEL with the sendkey command from the monitor window. You can simply run kill -INT 1, it should do the same thing as C-A-Del: C-A-Del only makes kernel send SIGINT to PID 1. So I'm surely doing something wrong, either in my inittab or in my config of busybox, but I don't see what. I even tried with the latest 1.20.2 (which I may use as the base for the next stable version) without more luck either. I also can't see any obvious problems. sigprocmask_allsigs(SIG_UNBLOCK); I read at http://lists.busybox.net/pipermail/busybox/2012-May/077855.html that a reason could be a non-busybox reboot but that's not our case. You can replace /sbin/reboot with something benign like /bin/touch /tmp/SIGINT_PID1_SEEN So I'm looking for advises on how to debug more, or any hint wrt my usage. Other people report that init may have some of its signals blocked. I am a bit skeptical, but it's easy to check. Find this place in init.c: die_sleep = 30 * 24*60*60; /* Figure out where the default console should be */ console_init(); and add this line: reset_sighandlers_and_unblock_sigs(); directly below die_sleep =... line. Then rebuild, install, reboot, and try SIGINT'ing init again. If it starts working after this modification, then it is indeed the case. Let me know what kernel version do you use then. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Denys ! You can simply run kill -INT 1, it should do the same thing as C-A-Del: C-A-Del only makes kernel send SIGINT to PID 1. For process 1 it is not! Signals send from another user to process 1 are handled somewhat different than signals send from the kernel. This includes automatically blocking of signals not handled by pid 1 (installed signal handler). sigprocmask_allsigs(SIG_UNBLOCK); May be the signal is not blocked but ignored, that is one of two issues leading to same problems. So in addition to sigprocmask you need to set all interrupts to there default action. Remember: If you exec to another program, signals ignored before the exec stay ignored after the exec. So if you ignore a signal for any purpose and forget to restore it's action to default the forked process will not receive such signals if it does not install a signal handler (can't receive ignored signal with signalfd or sigwaitinfo). From manpage of execve(2): * POSIX.1-2001 specifies that the dispositions of any signals that are ignored or set to the default are left unchanged. POSIX.1-2001 specifies one exception: if SIGCHLD is being ignored, then an implementa‐ tion may leave the disposition unchanged or reset it to the default; Linux does the former. And shells usually tend to not enable SIGINT if the signal is ignored on invocation of the shell (for none interactive shells = scripts). The caveat from this is, forking another shell from such a script does not restore SIGINT from it's ignored state. This blocks Ctrl-C in the forked shell even if the controlling tty is set correct. Hence my suggestion to add this sigprocmask to unblock all signals *AND* restore all signal actions to there default as part of the cttyhack applet. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On Fri, Mar 29, 2013 at 3:51 PM, Harald Becker ra...@gmx.de wrote: Hence my suggestion to add this sigprocmask to unblock all signals *AND* restore all signal actions to there default as part of the cttyhack applet. I would like to hear people confirming that kernel indeed blocks ant signals to pid 1. Which kernel version does that? -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Denys ! Hence my suggestion to add this sigprocmask to unblock all signals *AND* restore all signal actions to there default as part of the cttyhack applet. I would like to hear people confirming that kernel indeed blocks ant signals to pid 1. Which kernel version does that? May be you narrowed your focus a bit to much to the kernel. Sorry for my bad English and the misunderstandings it may produce. I'm no native English speaker. To clarify it a bit: - On Linux system startup from bare kernel to nothing else than a Busybox binary (startup script), I noticed at several times / system constellations issues due to signal actions not being processed. - Digging a bit into this, I found signals being either blocked (sigprocmask) *OR* ignored (action = SIG_IGN). - As at least some 2.4er Kernels mangled with the signals on startup, I did not look for the real reason of such signal blocking. I just added a simple wrapper to release the blocking that may have occurred ... and everything was fine for me. - As someone was asking for a problem which may be the result of such blocked signals I wanted to give a hint, why the signal may not be processed, even if you do a kill -SIGINT 1. - Restoring all signals action to there default and unblocking, before doing an exec to another program is good programming practice. To avoid searching for all the cases where this need to be done, I focused on the question, when is it required. Except the case of init it matters only when an interactive shell is started, as daemons usually setup there own signal handling without respect of signal setting on entrance. So the central place to trow that signal unblocking/default action restoring is the place used to startup the shell, usually the cttyhack applet. - Restoring signal actions to there default and unblocking doesn't harm if it's done without being required. It just waste some time/code space, but avoids lengthy debug sessions due to blocked signal handling. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
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 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
OK, so I have analyzed how a Debian Linux system boots. (Debian 6.0 with a 2.6.32 kernel, but I don't think it has changed much with newer kernels. The process is incredibly bloated - and I strongly suspect other mainstream distributions are just as bad, if not worse. Those guys do a lot of work in a pre-init initramfs; work that could easily be done in the real system, without an initramfs, if only people would realize that init is nothing sacred and can actually be a script that does early stuff before launching the long-running binary - which is actually exactly what they do, except they're hiding it in an initramfs as if it was shameful. I'm mentioning it because I had to dive deep into it to track the information I was looking for, and unneeded complexity in the boot process is one of my pet peeves. The binaries that run as process 1 before /sbin/init (which in my case is a SysVinit, but it would be the exact same thing with a systemd or anything else) are: * the initramfs shell, which is actually a Busybox shell. (I do not know whether it's hush or ash.) It is the first actual userspace binary launched by the kernel. * initramfs-tools' run-init binary, which acts as a transition between the /init shell script and the long-running /sbin/init binary. (Yeah, looks like they didn't manage to perform everything they wanted in the /init shell script, so they *still* had to insert some C code there. So much for flexibility and maintainability. Oops, I ranted again.) The run-init binary performs no signal handling at all. So if a some code performs signal blocking/unblocking between the kernel and the init process, it has to be the Busybox shell. Right before /sbin/init is launched, /proc/1/status shows *no* blocked signal. I haven't delved into ash and hush's source, because other people here will know their internals better than I will, but my conclusion for now is that it is *very unlikely* that the initial process 1 sigmask idea has anything to do with the problem. - Either the Linux kernel passes an empty sigmask to its first userspace binary (which I strongly believe is the case), and there is no problem here; as I already said, go investigate tty and job control, where unholy magicks are at work. - Or the Linux kernel passes a nonempty sigmask to process 1; but then the Busybox shell actually performs active sigmask management, since when it execs into something else, it has an empty sigmask. So in this case: * either it manages its sigmask correctly from the start, and there is no problem here - look somewhere else; * or it only cleans up the sigmask when executing, and incorrectly keeps some inherited blocked signals in its main loop. I'll leave the refutation (or bugfix !) here to the busybox shell experts. I'm still interested in hearing Rob on the inherited process 1 sigmask thing, or even in just pointers to relevant kernel-dev discussions. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Laurent, just a quick response as I'm late and busy today ... I haven't delved into ash and hush's source, because other people here will know their internals better than I will, but my conclusion for now is that it is *very unlikely* that the initial process 1 sigmask idea has anything to do with the problem. 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. - Either the Linux kernel passes an empty sigmask to its first userspace binary (which I strongly believe is the case), and there is no problem here; as I already said, go investigate tty and job control, where unholy magicks are at work. - Or the Linux kernel passes a nonempty sigmask to process 1; but then the Busybox shell actually performs active sigmask management, since when it execs into something else, it has an empty sigmask. So in this case: * either it manages its sigmask correctly from the start, and there is no problem here - look somewhere else; * or it only cleans up the sigmask when executing, and incorrectly keeps some inherited blocked signals in its main loop. I'll leave the refutation (or bugfix !) here to the busybox shell experts. I'm still interested in hearing Rob on the inherited process 1 sigmask thing, or even in just pointers to relevant kernel-dev discussions. 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. ... 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. This shows the problem is not, Busybox doing something wrong. It is just Busybox is missing to do something, required to enable normal signal response (in some usage cases, because getty seems to correct that problem - in getty started sessions everything looks fine). A suggestion: Add that signal unblocking stuff to cttyhack. If one needs to run shell scripts directly or has some corresponding trouble, he can run those applications trough an exec cttyhack. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
2) For situations where this it not possible (e.g. Busybox ash) I used a simple start wrapper to unblock signals. I'm curious: how come your process 1 ash had blocked signals ? Process 1 is launched by the kernel, and I haven't heard of a case where the kernel blocks signals before doing so. Or was it maybe something in your linuxrc blocking signals and failing to unblock them ? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
* Laurent Bercot ska-dietl...@skarnet.org [25.03.2013 12:18]: 2) For situations where this it not possible (e.g. Busybox ash) I used a simple start wrapper to unblock signals. I'm curious: how come your process 1 ash had blocked signals ? http://www.landley.net/hg/toybox/file/aad12ce05aae/toys/other/oneit.c PID 1 is special: can't exit, has various signals blocked bye, bastian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Laurent ! On 25-03-2013 10:33 Laurent Bercot ska-dietl...@skarnet.org wrote: 2) For situations where this it not possible (e.g. Busybox ash) I used a simple start wrapper to unblock signals. I'm curious: how come your process 1 ash had blocked signals ? Yes curious. I was afraid too. Process 1 is launched by the kernel, and I haven't heard of a case where the kernel blocks signals before doing so. Or was it maybe something in your linuxrc blocking signals and failing to unblock them ? No it's not the kernel, it is definitely Busybox, as it is the only binary involved in the testing environment. - no linuxrc at all - kernel starts /bin/init - /bin/init is a shell script #!/bin/busybox sh - shell script initializes system and mounts things, e.g. /proc - a cat /proc/1/status from script shows SIGINT (and others are either blocked or ignored) - script forks and starts a login shell with cttyhack on different console (/dev/tty2) - login shell comes up and looking into /proc it shows SIGINT is either blocked or ignored (depends on Busybox version) - verifying controlling terminal showed /dev/tty is controlling terminal of my login shell and the login shell is running as session leader (setsid after fork). - Ctrl-C doesn't work in this login shell, as SIGINT stays blocked or ignored in contrast: Starting the login shell via a wrapper, unblocking all signals and setting there handler to default enables Ctrl-C in my login shell. As this my /bin/sh is this wrapper. Unblock signals and than exec /bin/busybox sh passing through all arguments. ... and everything runs fine. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Bastian ! On 25-03-2013 12:20 Bastian Bittorf bitt...@bluebottle.com wrote: http://www.landley.net/hg/toybox/file/aad12ce05aae/toys/other/oneit.c PID 1 is special: can't exit, has various signals blocked If your oneit command is started with blocked signals or there action has been set to SIG_IGN this setting is inherited by the command you start. So it is better to set all signals to there default action and unblock before you do your exec. This way the started program has a clean signal handling on it's own session/process group. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
If your oneit command is started with blocked signals or there action has been set to SIG_IGN this setting is inherited by the command you start. So it is better to set all signals to there default action and unblock before you do your exec. This way the started program has a clean signal handling on it's own session/process group. Hi Harald, I believe Bastian was just quoting the oneit page to mention that PID 1 is special. It seems that the kernel sometimes launches process 1 with a nonempty set of blocked signals - apparently, Rob says so. I have never personally witnessed it, but getting a clean sigprocmask is one of the first duties of a long-running process 1, so it's not commonly observable. It makes sense that a shell running as process 1 (which it's not designed for) would have some trouble in this case because it has no reason to sigprocmask the world; but it's very weird that it wouldn't receive SIGINT, because a shell does want to catch, and actually handle, SIGINT, so it has to sig_unblock it sooner or later. I will experiment tomorrow, but my money isn't on the nonempty pid 1 sigprocmask thing. It's still on a tty/job control issue, which is far more voodoo (including the bloody, gory entrails) than signal stuff. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Bruno ! On 24-03-2013 18:11 Bruno Cornec br...@victoria.frmug.org wrote: I'll nee to try your advise to see whether I encounter the same situation. Just bring your board/emulator to the situation when CTRL-ALT-DEL does not work. Then access your system from a console or remote login shelll and do $ cat /proc/1/status | grep ^Sig The given numbers are hex with MSB on the left and LSB on the right, the bits correspond to the signals with bit #0 not used, bit #1 for SIGINT, etc. (for a list of signals see kill -l). SigPnd = currently pending signals SigBlk = blocked signals (sigprocmask) SigIgn = signals with action of SIG_IGN SigCgt = signals with an installed signal handler Is it linked to a specific kernel configuration/version ? The kernels behave somewhat different depending on versions and I can't tell you which versions show up the information in /proc/PID/status, but this signal handling has not much changed over time and I had such issues from start of 2.2 until current 3.8 kernels. Now, how did you unlock your proces (if possible) ? 1) Best is to change software to unblock/enable signal receiption at it's initialization time. 2) For situations where this it not possible (e.g. Busybox ash) I used a simple start wrapper to unblock signals. Something like this (untested and unverified from brain, so double check man pages): #include signal.h ... register int sig; struct sigaction sa; sa.sa_flags = 0; sa.sa_handler = SIG_DFL; sigemptyset(sa.sa_mask); for( sig=1; sig=SIGRTMAX; ++sig) sigaction(sig, sa, NULL); sigprocmask(SIG_SETMASK, sa.sa_mask, NULL); ... then exec to your program (execve or corresponding call) I do not know, if this works with Busybox init. May be init does it's own interrupt handling and overwrites your start wrapper. But it shall not harm in any way if all needed arguments/environment are passed on to your program. The wrapper just sets all signals to there default actions and unblock them to allow there delivery. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
Hi Bruno ! I'm testing mostly on KVM VMs, and simulate the CTRL-ALT-DEL with the sendkey command from the monitor window. This is working when we are at syslinux boot prompt, but as soon as we launch init, then we are unable to reboot the VM using CTRL-ALT-DEL. I also tested on real HW with the same result. A year ago or so I stumbled on a similar problem. After searching for a while, I found the process signals being blocked (look in /proc/PID/status, for init /proc/1/status). If process signals got blocked, the kernel signal for CTRL-ALT-DEL (SIGINT to process 1) can't be delivered. This is the same reason why Ctrl-C in a Busybox shell started directly from an linuxrc script is not working as expected (even when using cttyhack). May be this is your problem, so check /proc/1/status when CTRL-ALT-DEL does not work and look at the signal flags (SigBlk, SigIgn, SigCgt). -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
