unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Carlo Zancanaro <carlo@zancanaro.id.au>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 30948@debbugs.gnu.org
Subject: [bug#30948] [PATCH core-updates] guix: Reap finished child processes in build containers.
Date: Fri, 30 Mar 2018 22:17:06 +1100	[thread overview]
Message-ID: <87o9j5x1d4.fsf@zancanaro.id.au> (raw)
In-Reply-To: <87vadeou54.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

Hey,

On Fri, Mar 30 2018, Ludovic Courtès 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’s also “optional” because 
> 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.

>> 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).

> The “build side” is fully specified: ‘guix graph’ shows exactly 
> 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 “host side” code, users can use any Guile >= 2.0.13.

Yeah, okay. That makes sense. I guess I just expected 2.0.13 to be 
the minimum version throughout.

Carlo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2018-03-30 11:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 11:16 [bug#30948] [PATCH core-updates] guix: Reap finished child processes in build containers Carlo Zancanaro
2018-03-26 23:39 ` Carlo Zancanaro
2018-03-29 20:07 ` Ludovic Courtès
2018-03-29 21:15   ` Carlo Zancanaro
2018-03-30  8:16     ` Ludovic Courtès
2018-03-30 11:17       ` Carlo Zancanaro [this message]
2018-03-30 15:17         ` Ludovic Courtès
2022-11-24 16:40           ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o9j5x1d4.fsf@zancanaro.id.au \
    --to=carlo@zancanaro.id.au \
    --cc=30948@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).