all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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




  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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.