From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1s2n-0001ew-Cn for guix-patches@gnu.org; Fri, 30 Mar 2018 07:18:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1s2k-0005JO-A1 for guix-patches@gnu.org; Fri, 30 Mar 2018 07:18:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:51515) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1s2k-0005JG-6Q for guix-patches@gnu.org; Fri, 30 Mar 2018 07:18:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1s2j-0004q7-OV for guix-patches@gnu.org; Fri, 30 Mar 2018 07:18:01 -0400 Subject: [bug#30948] [PATCH core-updates] guix: Reap finished child processes in build containers. Resent-Message-ID: References: <87muyvulwt.fsf@zancanaro.id.au> <87bmf6ve6u.fsf@gnu.org> <87sh8id1mg.fsf@zancanaro.id.au> <87vadeou54.fsf@gnu.org> From: Carlo Zancanaro Message-ID: <87o9j5x1d4.fsf@zancanaro.id.au> In-reply-to: <87vadeou54.fsf@gnu.org> Date: Fri, 30 Mar 2018 22:17:06 +1100 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 30948@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hey, On Fri, Mar 30 2018, Ludovic Court=C3=A8s wrote: >> From what I can understand it's one of pid 1's responsiblities=20 >> to reap child processes, so I would expect this to be set up=20 >> for every builder, before the builder is run. > > True, but for derivations it=E2=80=99s also =E2=80=9Coptional=E2=80=9D be= cause=20 > eventually guix-daemon terminates all its child processes. As long as the build process doesn't rely on behaviour that,=20 strictly speaking, it should be allowed to rely on. It's not an=20 issue of resource leaking, it's an issue of correctness. >> Given it's not specific to the gnu-build-system, I don't think=20 >> it really fits there. > > Yes, but note that it would be inherited by all the build=20 > systems. Except for trivial-build-system, which is probably fine. I still=20 don't think it fits in a specific build system, given it's a=20 behaviour that transcends the specific action happening within the=20 container. Putting it in gnu-build-system will solve the problem in all=20 realistic cases, so that's probably fine. It's still subtly=20 incorrect, but will only be a problem if something using the=20 trivial build system relies on pid 1 to reap a process, or if we=20 make a new build system not deriving from gnu-build-system (which=20 seems unlikely, but not impossible). > The =E2=80=9Cbuild side=E2=80=9D is fully specified: =E2=80=98guix graph= =E2=80=99 shows exactly=20 > what Guile is used where, and you can see with, say: > > guix graph -t derivation \ > -e '(@@ (gnu packages commencement) findutils-boot0)' > > that the early derivations run on Guile 2.0.9. > > For =E2=80=9Chost side=E2=80=9D code, users can use any Guile >=3D 2.0.13. Yeah, okay. That makes sense. I guess I just expected 2.0.13 to be=20 the minimum version throughout. Carlo --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEwWt2bKTcV+mIZ20oCShLEsLiKqIFAlq+HLIACgkQCShLEsLi KqL7WAgAyftn/CJ0pPyDVc6L3qwhmU58s5hsT6U+E7TkRdkdf1NY6Hl1JK4JygJt FRFy7IuDgPWm4UpuBrCbHTbA5G7yzNoSqPzFiG+ephJmXvCyCg578NEfLD/ChUmz D/ES/rWw/rFmqTWTVxHZrnC7buiNOS9BgiiMkYbZ5cmAP1s77pzGFPKiZXoyp5zw zyn3lGPlh+ULvLGah+PdjLMM74qhIi7y3MDpGdRuHEFmCP4+vdz/33bZKwFqQ1YE Cj3Yi2tDPA4Ana0oAqCs4SMLGcseaZpAR4CmkDqaMq4t891k+JJ6EcvV45dFF0is 7gba+//F3RQAH9e1ujrp3SXCweO2GA== =qY0n -----END PGP SIGNATURE----- --=-=-=--