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/signalReceived on Thu Jul 07 2016 - 05:32:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC