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."