difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

[Matthew Macy]

 ---- On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov <ache at freebsd.org> wrote ---- 
 > On 07.07.2016 9:40, Matthew Macy wrote: 
 > >  
 > >  
 > >  
 > >  ---- On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov <ache at freebsd.org> wrote ----  
 > >  > On 07.07.2016 7:52, K. Macy wrote:  
 > >  > > On Wednesday, July 6, 2016, Don Lewis <truckman at freebsd.org> wrote:  
 > >  > >   
 > >  > >> On  6 Jul, Matthew Macy wrote:  
 > >  > >>> As a first step towards managing linux user space in a chrooted  
 > >  > >>> /compat/linux, initially for i915 testing with intel gpu tools, later  
 > >  > >>> on to get widevine and steam to work I'm trying to get apt to work.  
 > >  > >>> I've fixed a number of issues to date in pseudofs/linprocfs but now  
 > >  > >>> I'm running in to a bug caused by differences in SIGCHLD handling  
 > >  > >>> between Linux and FreeBSD. The situation is that apt will spawn dpkg  
 > >  > >>> and wait on a pipe read. On Linux when dpkg exits the  SIGCHLD to apt  
 > >  > >>> causes a short read on the pipe which lets apt then continue. On  
 > >  > >>> FreeBSD a SIGCHLD is silently ignored. I've even experimented with  
 > >  > >>> doing a kill -20 <apt pid> to no effect.  
 > >  > >>>  
 > >  > >>> It would be easy enough to check sysvec against linux in pipe_read and  
 > >  > >>> break out of the loop when it's awakened from msleep (assuming there  
 > >  > >>> aren't deeper issues with signal propagation for anything other than  
 > >  > >>> SIGINT/SIGKILL) and then do a short read. However, I'm assuming that  
 > >  > >>> anyone who has worked in this area probably has a cleaner solution.  
 > >  > >>  
 > >  > >> It shoulds like SA_RESTART is set in sa_flags for SIGCHLD but shouldn't  
 > >  > >> be in this case.  
 > >  > >   
 > >  > >   
 > >  > >   
 > >  > > Good point.  
 > >  > >   
 > >  > > Thinking more about it, this seems like a bug in FreeBSD. Not a valid  
 > >  > > behavioral difference.  
 > >  >   
 > >  > You better need consult with POSIX before fixing things toward any  
 > >  > Linuxisms blindly in our native code. I don't have a time now to see, is  
 > >  > it really a bug according to POSIX, but please read or just find all  
 > >  > SIGCHLD there:  
 > >  > http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html  
 > >  > it explain SIGCHLD actions in deep details.  
 > >  > And that one too:  
 > >  > http://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html  
 > >  
 > >  
 > >  
 > > I was pretty clear in my initial email that I'm only interested in changing behavior for Linux programs. 
 >  
 > Of course, but in case it is FreeBSD bug, it should be fixed in our 
 > native code first before making any changes in Linuxator. 
 >  
 > > And I was asking for help with that, not a link to SUSv3 or POSIX.  
 >  
 > In case I was not helpful, sorry for that. Before you try to change 
 > something in Linuxator you need to be sure that FreeBSD does it right 
 > (or wrong, then fix FreeBSD native code first). I am just insisting on 
 > proper steps of fixing it. 
 >  


I'm sorry for snapping . I misunderstood your intent. Using a SIGCHLD to deliberately interrupt a pipe read is such a weird idiom. I'll test fork vs clone on Linux and see how OS X responds to a SIGCHLD during a pipe read.

Thanks.
-M


 > _______________________________________________ 
 > freebsd-hackers at freebsd.org mailing list 
 > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers 
 > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org" 
 >