From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1vn4-0006S3-1P for guix-patches@gnu.org; Fri, 30 Mar 2018 11:18:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1vn0-0007h3-22 for guix-patches@gnu.org; Fri, 30 Mar 2018 11:18:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:52460) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1vmz-0007gb-Ue for guix-patches@gnu.org; Fri, 30 Mar 2018 11:18:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1vmz-0001d6-JS for guix-patches@gnu.org; Fri, 30 Mar 2018 11:18:01 -0400 Subject: [bug#30948] [PATCH core-updates] guix: Reap finished child processes in build containers. Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87muyvulwt.fsf@zancanaro.id.au> <87bmf6ve6u.fsf@gnu.org> <87sh8id1mg.fsf@zancanaro.id.au> <87vadeou54.fsf@gnu.org> <87o9j5x1d4.fsf@zancanaro.id.au> Date: Fri, 30 Mar 2018 17:17:29 +0200 In-Reply-To: <87o9j5x1d4.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Fri, 30 Mar 2018 22:17:06 +1100") Message-ID: <874lkxoanq.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Carlo Zancanaro Cc: 30948@debbugs.gnu.org Hello, Carlo Zancanaro skribis: > On Fri, Mar 30 2018, Ludovic Court=C3=A8s wrote: >>> From what I can understand it's one of pid 1's responsiblities to >>> reap child processes, so I would expect this to be set up for every >>> builder, before the builder is run. >> >> True, but for derivations it=E2=80=99s also =E2=80=9Coptional=E2=80=9D b= ecause eventually >> guix-daemon terminates all its child processes. > > As long as the build process doesn't rely on behaviour that, strictly > speaking, it should be allowed to rely on. It's not an issue of > resource leaking, it's an issue of correctness. Right. >>> Given it's not specific to the gnu-build-system, I don't think it >>> really fits there. >> >> Yes, but note that it would be inherited by all the build systems. > > Except for trivial-build-system, which is probably fine. I still don't > think it fits in a specific build system, given it's a behaviour that > transcends the specific action happening within the container. > > Putting it in gnu-build-system will solve the problem in all realistic > cases, so that's probably fine. It's still subtly incorrect, but will > only be a problem if something using the trivial build system relies > on pid 1 to reap a process, or if we make a new build system not > deriving from gnu-build-system (which seems unlikely, but not > impossible). I agree, every Guile process running as PID=C2=A01 should reap processes. My view is just that this mechanism belongs in =E2=80=9Cuser code=E2=80=9D,= not in the low-level mechanisms such as =E2=80=98build-expression->derivation=E2=80=99= and =E2=80=98gexp->derivation=E2=80=99. It=E2=80=99s a matter of separation of= concerns. Of course we don=E2=80=99t want to duplicate that code every time, but the = way we should factorize it, IMO, is by putting it in a =E2=80=9Cnormal=E2=80=9D= module that people will use. Putting it in gnu-build-system is an admittedly hacky but easy way to have it widely shared. Thanks, Ludo=E2=80=99.