Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On 7/18/16 4:15 PM, Matthew Macy wrote: On Mon, 18 Jul 2016 16:11:53 -0700 Alfred Perlstein wrote > I believe the > > > On 7/6/16 9:34 PM, 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 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. > > > > Thanks in advance. > > Are you sure you need a hack in pipe_read and not one of the following > possibilities: > 1) a setting for the default signal disposition for linux processes > needs to be fixed. > 2) a flag set in p_flag2 that says set this behavior properly in a > generic manner. > > Again not sure why you need to hack pipe_read and not just make sure > that SIGCHLD is generated... > > Finally that sure is oddball behavior, dpkg probably has a bug where the > parent is keeping the write side of the pipe open, you might be able to > get them to take a patch upstream to fix that. > If you read my final mail it turns out I was holding a reference to the pipe in question in linprocfs. Maintaining the reference kept apt from getting the EOF on the pipe. I've since fixed this. -M Ah that makes sense. :) -Alfred ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On Mon, 18 Jul 2016 16:11:53 -0700 Alfred Perlstein wrote > I believe the > > > On 7/6/16 9:34 PM, 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 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. > > > > Thanks in advance. > > Are you sure you need a hack in pipe_read and not one of the following > possibilities: > 1) a setting for the default signal disposition for linux processes > needs to be fixed. > 2) a flag set in p_flag2 that says set this behavior properly in a > generic manner. > > Again not sure why you need to hack pipe_read and not just make sure > that SIGCHLD is generated... > > Finally that sure is oddball behavior, dpkg probably has a bug where the > parent is keeping the write side of the pipe open, you might be able to > get them to take a patch upstream to fix that. > If you read my final mail it turns out I was holding a reference to the pipe in question in linprocfs. Maintaining the reference kept apt from getting the EOF on the pipe. I've since fixed this. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
I believe the On 7/6/16 9:34 PM, 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 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. Thanks in advance. Are you sure you need a hack in pipe_read and not one of the following possibilities: 1) a setting for the default signal disposition for linux processes needs to be fixed. 2) a flag set in p_flag2 that says set this behavior properly in a generic manner. Again not sure why you need to hack pipe_read and not just make sure that SIGCHLD is generated... Finally that sure is oddball behavior, dpkg probably has a bug where the parent is keeping the write side of the pipe open, you might be able to get them to take a patch upstream to fix that. -Alfred ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
> Unsurprisingly I may have misinterpreted the trace. > > John observes: > Alternatively, if apt is creating a pipe() that it passes to dpkg() via > fork() and apt > only creates the read end opened and dpkg only keeps the write end up > opened, then when > dpkg exits, the pipe_read should return EOF when dpkg exits (that is > normally the way pipes > are used to detect child exit rather than EINTR from SIGCLD). > > The SIGCHLD may be a red herring as strace will report it even if it is > ignored. What John describes is borne out by the traces. > > FreeBSD from pipe creation to dpkg exit and apt hang > http://pastebin.com/TGRrMniD > > Linux from pipe creation to dpkg exit and apt continue > http://pastebin.com/wPfd31Pf It turns out that this was footshooting. In my changes to linprocfs the /fd directory was holding additional references to the struct file pointers which prevented apt from getting an EOF when dpkg exited. Thanks to all who commented. FWIW, after fixing the previous issue and then linux_mremap to be able to grow a mapping apt works now: root@planecrash:/home/mmacy # chroot /compat/linux/ apt-get update Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [94.5 kB] Hit:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease Fetched 94.5 kB in 1s (56.3 kB/s) Reading package lists... Done I don't think this is all that useful until I update / implement any system calls to get steam / widevine whatever working, but in case anyone cares this is all going on in the drm-next-4.6 branch alongside the graphics work. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On Thu, 07 Jul 2016 07:04:24 -0700 Konstantin Belousov wrote > On Thu, Jul 07, 2016 at 12:14:52AM -0700, Don Lewis wrote: > > On 6 Jul, Matthew Macy wrote: > > > > > > > > > > > > On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov > > > wrote > > > > On 07.07.2016 9:40, Matthew Macy wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov > > > > > wrote > > > > > > On 07.07.2016 7:52, K. Macy wrote: > > > > > > > On Wednesday, July 6, 2016, Don Lewis > > > > > > > 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 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? > > BSD traditional and allowed handling of the signals with SIG_IGN > disposition is to discard such signal at the time of generation. Then, > such signal cannot interrupt a syscall regardless of SA_RESTART. For > the interruption to work, some signal handler must be installed. >
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On Thu, Jul 07, 2016 at 12:14:52AM -0700, Don Lewis wrote: > On 6 Jul, Matthew Macy wrote: > > > > > > > > On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov > > wrote > > > On 07.07.2016 9:40, Matthew Macy wrote: > > > > > > > > > > > > > > > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov > > > > wrote > > > > > On 07.07.2016 7:52, K. Macy wrote: > > > > > > On Wednesday, July 6, 2016, Don Lewis > > > > > > 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 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? BSD traditional and allowed handling of the signals with SIG_IGN disposition is to discard such signal at the time of generation. Then, such signal cannot interrupt a syscall regardless of SA_RESTART. For the interruption to work, some signal handler must be installed. AFAIR both SysV and Linux do not discard ignored signals, but process them up to the delivery point. Sure the test demonstrating the difference is required to actually diagnose and make conclusions. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
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 >> wrote >> > On 07.07.2016 9:40, Matthew Macy wrote: >> > > >> > > >> > > >> > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov >> > > wrote >> > > > On 07.07.2016 7:52, K. Macy wrote: >> > > > > On Wednesday, July 6, 2016, Don Lewis >> > > > > 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 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On 6 Jul, Matthew Macy wrote: > > > > On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov > wrote > > On 07.07.2016 9:40, Matthew Macy wrote: > > > > > > > > > > > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov > > > wrote > > > > On 07.07.2016 7:52, K. Macy wrote: > > > > > On Wednesday, July 6, 2016, Don Lewis > > > > > 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 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? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov wrote > On 07.07.2016 9:40, Matthew Macy wrote: > > > > > > > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov > > wrote > > > On 07.07.2016 7:52, K. Macy wrote: > > > > On Wednesday, July 6, 2016, Don Lewis 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 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-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On 07.07.2016 9:40, Matthew Macy wrote: > > > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov > wrote > > On 07.07.2016 7:52, K. Macy wrote: > > > On Wednesday, July 6, 2016, Don Lewis 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 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov wrote > On 07.07.2016 7:52, K. Macy wrote: > > On Wednesday, July 6, 2016, Don Lewis 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 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. And I was asking for help with that, not a link to SUSv3 or POSIX. On closer reading of the man pages it looks like linux's clone is supposed to change the disposition for the exit signal. I'll have to write a test program to reproduce this behavior in isolation. -M > > > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On 07.07.2016 7:52, K. Macy wrote: > On Wednesday, July 6, 2016, Don Lewis 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 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
On Wednesday, July 6, 2016, Don Lewis 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 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. -M > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > " > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
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 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
difference in SIGCHLD behavior between Linux and FreeBSD breaks apt
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 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. Thanks in advance. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
