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. How does apt set up its handling of SIGCHLD?Received on Thu Jul 07 2016 - 05:15:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC