This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: [sbachman@saveware.com] libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
- To: aj at suse dot de
- Subject: Re: [sbachman@saveware.com] libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Fri, 14 Jan 2000 13:52:46 -0800
- CC: libc-alpha at sourceware dot cygnus dot com, sbachman at saveware dot com
- References: <u8puv4mkst.fsf@gromit.rhein-neckar.de>
> Cc: sbachman@saveware.com
> From: Andreas Jaeger <aj@suse.de>
> Date: 14 Jan 2000 21:59:30 +0100
> Hi glibc developers & testers,
>
> We've received the appended bug report. For me this looks like a bug
> in the kernel. AFAIK Posix explicitly mentions execl as a function
> which is allowed to be called from a signal handler (printf is not
> signal safe but I don't think that this is the problem here).
>
> What do you think? Should this be forwarded to linux-kernel?
I don't think this is a bug. In the signal handler, signals are
blocked until the handler is exited. Signal masks are inherited by
child processes. You probably want to set SA_NODEFER.
--
- Geoffrey Keating <geoffk@cygnus.com>