I think that's an application bug.
The kernel does the obvious (and required) thing: it preserves the
list of blocked signals over the execve(). And if you call execve() from
within a signal handler, that list of blocked signals will obviously
include the signals that got blocked by the execution of the signal
itself.
(Side note: I also suspect that the program is not strictly POSIX
conforming, and that execve() isn't in the list of functions that are safe
to call from a signal handler in the first place, but that's a totally
separate issue).
So if havign the signal blocked isn't what the application wants, I'd
suggest one of:
- just set the signal mask by hand to whatever mask you want (perhaps
also marking the signal handler with SIGIGN or SIGDFL or whatever)
- alternatively, if you control the program being execve'd, just do it in
that progam instead.
- use siglongjmp in the signal handler to get out of the signal handler
context and do it that way.
- use a "sigatomic_t" flag, set it in the signal handler, and then do the
execve() in the main loop if it's set.
The last one is the safest one in many ways (since it doesn't care if you
get a hundred of those signals in close succession - and you could also
make it a counter or something if you want to actually count those
things).
Linus
--
