difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
Andrey Chernov
ache at freebsd.org
Thu Jul 7 07:32:09 UTC 2016
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 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.
>
> 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
More information about the freebsd-current
mailing list