signalfd() semantics after execve()

signalfd() semantics after execve()

[Michael Kerrisk]

Davide, 

I'm working on the signalfd(2) man page, and I've come
acorss some puzzling behaviour...  

What are the intended semantics of a signalfd file descriptor
after an execve()?

As far as I can work out, after an execve() the file descriptor
is still available, but reads from it always return 0, even if:

a) there were signals pending before the execve().
   However, sigpending() shows the signal as pending,
   and the signal can be accepted using sigwaitinfo().

b) we generate a signal after the execve().
 
Is this intended behavior (the "orphaned sighand" condition
mentioned in the draft man page you sent me?)?  Is it a bug?

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

Re: signalfd() semantics after execve()

[Davide Libenzi]

On Sat, 14 Jul 2007, Michael Kerrisk wrote:

> Davide, 
> 
> I'm working on the signalfd(2) man page, and I've come
> acorss some puzzling behaviour...  
> 
> What are the intended semantics of a signalfd file descriptor
> after an execve()?
> 
> As far as I can work out, after an execve() the file descriptor
> is still available, but reads from it always return 0, even if:
> 
> a) there were signals pending before the execve().
>    However, sigpending() shows the signal as pending,
>    and the signal can be accepted using sigwaitinfo().
> 
> b) we generate a signal after the execve().
>  
> Is this intended behavior (the "orphaned sighand" condition
> mentioned in the draft man page you sent me?)?  Is it a bug?

It is the intended behaviour. Just like reading from a socket where the 
remote peer disconnected. A return 0 from a read from a signalfd should be 
interpreted as the "virtual connection" with the signal source has been 
dropped.



- Davide

Re: signalfd() semantics after execve()

[Michael Kerrisk]

Davide,

> > I'm working on the signalfd(2) man page, and I've come
> > acorss some puzzling behaviour...  
> > 
> > What are the intended semantics of a signalfd file descriptor
> > after an execve()?
> > 
> > As far as I can work out, after an execve() the file descriptor
> > is still available, but reads from it always return 0, even if:
> > 
> > a) there were signals pending before the execve().
> >    However, sigpending() shows the signal as pending,
> >    and the signal can be accepted using sigwaitinfo().
> > 
> > b) we generate a signal after the execve().
> >  
> > Is this intended behavior (the "orphaned sighand" condition
> > mentioned in the draft man page you sent me?)?  Is it a bug?
> 
> It is the intended behaviour. Just like reading from a socket where the 
> remote peer disconnected. 

I don't think this analogy is good; what is the "peer" in this 
situation?

IMO, A better analogy is: signalfd() should provide 
similar semantics to sigwaitinfo()/sigtimedwait() (and/or
handling signals with a signal handler).

> A return 0 from a read from a signalfd should be
> interpreted as the "virtual connection" with the signal source has been 
> dropped.

Yes, but in this case why has the '"virtual connection" with the 
signal source' been dropped?  

Why shouldn't one be allowed to continue reading signals from
the signalfd file descriptor after the execve()?  

After all, I can still fetch those signals with sigwaitinfo() 
after the execve().  Not being able to also dothat with signalfd 
just isn't consistent.

Cheers,

Michael
-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.