[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