[BusyBox] init blocks signals and forgets to clear signal mask before executing news processes
Jean Wolter
jw5 at os.inf.tu-dresden.de
Fri Oct 3 17:34:42 UTC 2003
"Vladimir N. Oleynik" <dzo at simtreas.ru> writes:
> > init blocks signals (especially SIGHUP) and forgets to clear the
> > signal mask before calling execve. Therefore new processes never see
> > SIGHUP if they don't unblock it themself.
>
> I not found documentation from man pages for this and lookup from kernel source: ;-)
>
> from fs/exec.c
> /* * This function makes sure the current process has its own signal
> table, * so that flush_signal_handlers can later reset the handlers
> without */ from kernel/signal.c
>
>
> flush_signal_handlers(struct task_struct *t) { int i;
> struct k_sigaction *ka = &t->sig->action[0]; for (i = _NSIG ;
> i != 0 ; i--) { if (ka->sa.sa_handler != SIG_IGN)
> ka->sa.sa_handler = SIG_DFL; ka->sa.sa_flags = 0;
> sigemptyset(&ka->sa.sa_mask); ka++; } }
>
>
>
> So. After exec() all signal unblocked. This is good right.
There is sigaction() and sigprocmask(). The code you mentioned removes
any signal handler set via sigaction() (except SIG_IGN). But SIGHUP
ist *blocked* via sigprocmask and this is inherited via execve.
Write a small programm, start it via init, read your current list of
blocked signals using sigprocmask and you will see, that SIGHUP is
blocked (not ignored).
> Also. This init.c part code have full equivalent sysvinit package.
Really?
> You have really problem?
Yes. None of our daemons was doing anything after it got a SIGHUP,
after we switch from 0.60.5 to 1.0-pre3 and after the work around they
behave as expected.
regards,
Jean
More information about the busybox
mailing list