Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jul 2016 10:32:05 +0300
From:      Andrey Chernov <ache@freebsd.org>
To:        Don Lewis <truckman@FreeBSD.org>, mmacy@nextbsd.org
Cc:        freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, kmacy@freebsd.org
Subject:   Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
Message-ID:  <325f545e-a32d-59d8-86d3-079ecdf21df2@freebsd.org>
In-Reply-To: <201607070714.u677EqVx008159@gw.catspoiler.org>
References:  <201607070714.u677EqVx008159@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 07.07.2016 10:14, Don Lewis wrote:
> On  6 Jul, Matthew Macy wrote:
>>
>>
>>
>>  ---- On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov
>>  <ache@freebsd.org> wrote ----
>>  > On 07.07.2016 9:40, Matthew Macy wrote: 
>>  > >  
>>  > >  
>>  > >  
>>  > >  ---- On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov
>>  > >  <ache@freebsd.org> wrote ----
>>  > >  > On 07.07.2016 7:52, K. Macy wrote:  
>>  > >  > > On Wednesday, July 6, 2016, Don Lewis <truckman@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.
> 
> It really depends on how signal handling has been set up.  From my
> understanding of the FreeBSD man pages and the Open Group documents, the
> default handling for SIGCHLD is to just ignore it, in which case it
> shouldn't interrupt the pipe read.  If the process has set up a SIGCHLD
> signal handler, then what happens with the read should depend on whether
> or not SA_RESTART was passed to sigaction().  I would expect that Linux
> would be the same as FreeBSD and the Open Group specs.

Linux as SysV derivative was always different regarding to SA_RESTART
and other SA_* flags for signal(), see differences at the end of:
http://linux.die.net/man/2/signal





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?325f545e-a32d-59d8-86d3-079ecdf21df2>