From: bo0od <bo0od@riseup.net>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: 47717@debbugs.gnu.org
Subject: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
Date: Wed, 14 Apr 2021 16:54:51 +0000 [thread overview]
Message-ID: <4e1f8d67-2329-6ba1-4e21-9ec978de3cb3@riseup.net> (raw)
In-Reply-To: <87czuxem1r.fsf@nckx>
> I mean the ‘outrageously’ part. When Linux runs out of memory, it
> freezes up. Moral judgment is futile. Better to adopt raingloom's
> earlyoom suggestion or similar.
Im using default guix system nothing special, If this package usable to
solve these stuff i suggest then to include it by default.
I suggest as well to take a look at solutions similar to this one:
https://forums.whonix.org/t/constrained-system-resources-program-starter-wrapper/10914
or even at least possibility of switch virtual console, login as
different user and kill the broken processes exhausting system resources.
> I did, hence the question. ;-) The file I asked for is missing.
No, Please check the ticket on the website as i provided the needed log
as .txt file but somehow the website(guix issues) fetching it to plain
text and seems it didnt reach to you. Here is the link to the ticket:
https://issues.guix.gnu.org/47717
> 4 GiB is absolutely not enough to build an outrageous amount of ‘modern’
> software, especially in parallel (so not using --cores=1 --max-jobs=1)
> to make use of those expensive cores.
>
> I'm disgusted too.
Yes it is, But you know this cant be a way of life with guix for end
user no? Something by default should solve this matter otherwise this is
not usable distro.
> Oh, nor do I. My point is this isn't a bug in Guix, so it's not a bug
> we can ‘fix’. A ‘workaround’ is the best we can do.
So you gonna wait for every user to open xyz tickets and you gonna
answer them 1 by 1 the same answer this is not our issue? I dont see
this is good idea even if its true its not entirely guix issue but guix
need to find out something to close this gap otherwise prepare to see
more like this report.
> I think the installer now asks whether you want to enable substitutes.
> Do you remember if it did? If you chose not to, why not, and do you
> feel like you were making an informed decision?
I used manual installation, didnt see this.
> This won't happen. Enabling substitutes requires informed administrator
> consent. If that's an issue -- and I bet it is! -- we need to do a
> better job educating them during installation, no later.
Yes if guix can indicate the amount of RAM is low then it can popup a
message telling the user due to low RAM and to avoid resources
exhausting would you like to activate x to avoid this issue? <-
something like this can be done.
Tobias Geerinckx-Rice:
> bo0od writes:
>> yes sound dramatic but i couldnt describe what happened better.
>
> I mean the ‘outrageously’ part. When Linux runs out of memory, it
> freezes up. Moral judgment is futile. Better to adopt raingloom's
> earlyoom suggestion or similar.
>
>> /var/log/guix/drvs/5a/8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv.bz2
>>
>> check the uploaded .txt file
>
> I did, hence the question. ;-) The file I asked for is missing.
>
>> 4G of ram not enough? That would be interesting if its not.
>
> Prepare to be interested, I guess... y... yaay...
>
> 4 GiB is absolutely not enough to build an outrageous amount of ‘modern’
> software, especially in parallel (so not using --cores=1 --max-jobs=1)
> to make use of those expensive cores.
>
> I'm disgusted too.
>
>> No, i dont like workarounds
>
> Oh, nor do I. My point is this isn't a bug in Guix, so it's not a bug
> we can ‘fix’. A ‘workaround’ is the best we can do.
>
> For example, one such workaround would be to ask the user whether they
> want to run the daemon in ‘slow mode’ (--cores=1 --max-jobs=1 etc.) if
> we detect <N GiB of RAM during installation.
>
> But with only 4 GiB of RAM and -j1 some ‘modern’ things will still
> fail. At that point you offload or accept substitutes, and I think
> doing either selectively is pointless.
>
>> If substitutes are essentials for users then it should be enabled by
>> default ,
>
> I didn't say they were essential; they're not. They're an alternative
> to downloading more RAM.
>
> I think the installer now asks whether you want to enable substitutes.
> Do you remember if it did? If you chose not to, why not, and do you
> feel like you were making an informed decision?
>
>> or switched automatically if there is something bad happened like this
>> issue.
>
> This won't happen. Enabling substitutes requires informed administrator
> consent. If that's an issue -- and I bet it is! -- we need to do a
> better job educating them during installation, no later.
>
> Kind regards,
>
> T G-R
next prev parent reply other threads:[~2021-04-14 17:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 5:39 bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure bo0od
2021-04-12 18:04 ` bug#47717: guix becomes unresponsive while building the 'vigra' package Leo Famulari
2021-04-13 11:03 ` bo0od
2021-04-13 17:35 ` Leo Famulari
2021-04-14 16:06 ` bo0od
2021-04-14 8:21 ` Mark H Weaver
2021-04-14 17:08 ` bo0od
2021-04-12 18:41 ` bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure Tobias Geerinckx-Rice via Bug reports for GNU Guix
2021-04-12 22:59 ` raingloom
2021-04-13 11:34 ` bo0od
2021-04-14 0:40 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2021-04-14 16:54 ` bo0od [this message]
2021-04-15 19:56 ` Mark H Weaver
2021-04-16 3:08 ` bo0od
2021-04-21 1:35 ` Maxim Cournoyer
2021-04-22 18:34 ` Mark H Weaver
2021-04-25 8:14 ` Efraim Flashner
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=4e1f8d67-2329-6ba1-4e21-9ec978de3cb3@riseup.net \
--to=bo0od@riseup.net \
--cc=47717@debbugs.gnu.org \
--cc=me@tobias.gr \
/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).