Subject: Re: kern/5504: signal handler does not get called again after execve
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Andrew Brown <twofsonet@graffiti.com>
List: netbsd-bugs
Date: 05/28/1998 09:09:31
>On Thu, May 28, 1998 at 07:51:17AM -0400, der Mouse wrote:
>> >Release: 1.2
>
>You're unlikely to get anything but "upgrade!", unless this proves to
>be present in -current.
it probably is, since it's in the man pages. now that that's been
pointed out to me, all i can ask is, why?
>> >How-To-Repeat:
>> write a program that re-execs itself after receiving a SIGHUP.
>> send it a SIGHUP. then send the new process a SIGHUP. notice
>> that it doesn't work.
>
>This "how" is woefully incomplete. I'd want to see full code to the
>test program - for example, if you re-exec() directly in the SIGHUP
>handler, the exec will happen with SIGHUP blocked, and the usual
>unblocking mechanism upon exiting a signal handler will not get a
>chance to run because the signal handler does not exit. But if you
>just set a volatile sig_atomic_t variable and exec from the main line,
>something weirder is going on.
yes, sorry. i didn't make that very clear. yes, i am re-execing
directly from the signal handler. and, no, it appears the "unblocking
mechanism" is not getting run.
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
warfare@graffiti.com * "information is power -- share the wealth."