From owner-freebsd-current@freebsd.org Thu Jul 7 04:34:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B84CB75CD4; Thu, 7 Jul 2016 04:34:08 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 214D21CB0; Thu, 7 Jul 2016 04:34:07 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467866046079240.9597104517618; Wed, 6 Jul 2016 21:34:06 -0700 (PDT) Date: Wed, 06 Jul 2016 21:34:06 -0700 From: Matthew Macy To: "freebsd-current@freebsd.org" , "freebsd-hackers@freebsd.org" Message-ID: <155c3a25e3f.11fb4143170445.2284890475527649192@nextbsd.org> Subject: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 04:34:08 -0000 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