GNU bug report logs - #47717
Avoid system freezes by using earlyoom (with D-Bus notifications)

Previous Next

To reply to this bug, email your comments to 47717 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bo0od <bo0od <at> riseup.net>
To: bug-guix <at> gnu.org
Subject: guix outrageously exhaust itself (freeze) when there is package build
 failure
Date: Mon, 12 Apr 2021 05:39:11 +0000

[Message part 1 (text/plain, inline)]

Hi There,

I have used "guix pull" then "guix upgrade" one of the packages couldnt 
be built but thats not the real issue, The real issue it caused guix to 
freeze for like not less than 2+ hours and i couldnt do anything with 
the distro until guix cut out the build/upgradation by itself.

check the uploaded content.

[guixfreeze.png (image/png, attachment)]

[guixfreeze.txt (text/plain, attachment)]

Message #10 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: bo0od <bo0od <at> riseup.net>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix becomes unresponsive while building the 'vigra'
 package
Date: Mon, 12 Apr 2021 14:04:24 -0400

On Mon, Apr 12, 2021 at 05:39:11AM +0000, bo0od wrote:
> I have used "guix pull" then "guix upgrade" one of the packages couldnt be
> built but thats not the real issue, The real issue it caused guix to freeze
> for like not less than 2+ hours and i couldnt do anything with the distro
> until guix cut out the build/upgradation by itself.
> 
> check the uploaded content.

[...]

> building /gnu/store/5a8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv...
>  42% [#############################                                         ]builder for `/gnu/store/5a8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv' failed with exit code 1
> build of /gnu/store/5a8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv failed
> View build log at '/var/log/guix/drvs/5a/8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv.bz2'.

So, it failed to build 'vigra'. This package is notoriously expensive to
build, although it's not expected that your computer would stop
responding.

What kind of computer are you using? Are you using swap?

Ideally, we'd have a substitute for this...

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bo0od <bo0od <at> riseup.net>
Cc: 47717 <at> debbugs.gnu.org, bug-guix <at> gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Mon, 12 Apr 2021 20:41:00 +0200

[Message part 1 (text/plain, inline)]

Hi bo0od,

Your subject was quite dramatic and probably not true.  Try to 
avoid both.

bo0od writes:
> The real issue it caused guix to freeze for like not less than 
> 2+
> hours and i couldnt do anything with the distro until guix cut 
> out
> the build/upgradation by itself.

Take a look at (and next time, attach)

 $ bzless 
 /var/log/guix/drvs/5a/8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv.bz2

the log file mentioned in the error message.  You'll probably find 
the string ‘Killed’ near the end.  If you haven't rebooted yet,

 $ grep oom /proc/vmstat

will probably return something non-zero.

If so: you ran out of memory while building a heavy package.  This 
causes your system to become unresponsive whilst it tries to 
postpone that for as long as possible.  This is a fact of Linux.

You can try to work around it by adding RAM, passing ‘-{M,c}1’ to 
the guix command that failed, and/or enabling swap, but the root 
cause is you simply don't have enough memory to build this package 
at its default settings.

Or, you can make sure you download a substitute instead of trying 
to build everything locally.  At the time of writing (commit 
d14f213) there's a libreoffice substitute on ci.guix.gnu.org.  Are 
substitutes configured and enabled?

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):

From: raingloom <raingloom <at> riseup.net>
To: Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: bo0od <bo0od <at> riseup.net>, Tobias Geerinckx-Rice <me <at> tobias.gr>,
 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Tue, 13 Apr 2021 00:59:34 +0200

On Mon, 12 Apr 2021 20:41:00 +0200
Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix <at> gnu.org>
wrote:

> Hi bo0od,
> 
> Your subject was quite dramatic and probably not true.  Try to 
> avoid both.
> 
> bo0od writes:
> > The real issue it caused guix to freeze for like not less than 
> > 2+
> > hours and i couldnt do anything with the distro until guix cut 
> > out
> > the build/upgradation by itself.  
> 
> Take a look at (and next time, attach)
> 
>   $ bzless 
>   /var/log/guix/drvs/5a/8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv.bz2
> 
> the log file mentioned in the error message.  You'll probably find 
> the string ‘Killed’ near the end.  If you haven't rebooted yet,
> 
>   $ grep oom /proc/vmstat
> 
> will probably return something non-zero.
> 
> If so: you ran out of memory while building a heavy package.  This 
> causes your system to become unresponsive whilst it tries to 
> postpone that for as long as possible.  This is a fact of Linux.
> 
> You can try to work around it by adding RAM, passing ‘-{M,c}1’ to 
> the guix command that failed, and/or enabling swap, but the root 
> cause is you simply don't have enough memory to build this package 
> at its default settings.
> 
> Or, you can make sure you download a substitute instead of trying 
> to build everything locally.  At the time of writing (commit 
> d14f213) there's a libreoffice substitute on ci.guix.gnu.org.  Are 
> substitutes configured and enabled?
> 
> Kind regards,
> 
> T G-R

Also this is an issue in general with the Linux OOM killer. I recommend
installing earlyoom. It's already packaged in Guix and there is even a
service description for it.
It will help with the freezing issue.

Message #25 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: bo0od <bo0od <at> riseup.net>
To: Leo Famulari <leo <at> famulari.name>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix becomes unresponsive while building the 'vigra'
 package
Date: Tue, 13 Apr 2021 11:03:50 +0000

> What kind of computer are you using? Are you using swap?

4GB DDR3 rams, i7 4th generation , 20GB for Guix about 9GB swap

If this is not enough to install simple common used packages like 
libreoffice or onionshare..etc then this is big issue if guix considered 
to be targeting average users.

In Qubes distro 4GB is worthless/nothing the minimum is like 8GB and 
above. If guix is the same thing then no problem but for surely it need 
to be mentioned somewhere obvious(i didnt find it anywhere saying that).


> On Mon, Apr 12, 2021 at 05:39:11AM +0000, bo0od wrote:
>> I have used "guix pull" then "guix upgrade" one of the packages couldnt be
>> built but thats not the real issue, The real issue it caused guix to freeze
>> for like not less than 2+ hours and i couldnt do anything with the distro
>> until guix cut out the build/upgradation by itself.
>>
>> check the uploaded content.
> 
> [...]
> 
>> building /gnu/store/5a8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv...
>>   42% [#############################                                         ]builder for `/gnu/store/5a8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv' failed with exit code 1
>> build of /gnu/store/5a8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv failed
>> View build log at '/var/log/guix/drvs/5a/8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv.bz2'.
> 
> So, it failed to build 'vigra'. This package is notoriously expensive to
> build, although it's not expected that your computer would stop
> responding.
> 
> What kind of computer are you using? Are you using swap?
> 
> Ideally, we'd have a substitute for this...
> 

Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bo0od <bo0od <at> riseup.net>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 47717 <at> debbugs.gnu.org, bug-guix <at> gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Tue, 13 Apr 2021 11:34:41 +0000

[Message part 1 (text/plain, inline)]

> Your subject was quite dramatic and probably not true.  Try to avoid 
both.

yes sound dramatic but i couldnt describe what happened better. about 
"not true" i posted the error message and i dunno if there is something 
i can post describing when there is freeze.

> Take a look at (and next time, attach)
>
>   $ bzless
> 
/var/log/guix/drvs/5a/8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv.bz2

check the uploaded .txt file

> the log file mentioned in the error message.  You'll probably find the
> string ‘Killed’ near the end.  If you haven't rebooted yet,
>
>   $ grep oom /proc/vmstat

i already rebooted the machine.

> but the root cause is
> you simply don't have enough memory to build this package at its default
> settings.

4G of ram not enough? That would be interesting if its not.

> there's a libreoffice substitute on ci.guix.gnu.org.  Are substitutes
> configured and enabled?

No, i dont like workarounds because when i report bugs i try to put 
myself in the position of new user. If substitutes are essentials for 
users then it should be enabled by default , or switched automatically 
if there is something bad happened like this issue. And if its not then 
the default configurations has something need to be fixed/improved to 
avoid issues like the one i have reported.



> Hi bo0od,
> 
> Your subject was quite dramatic and probably not true.  Try to avoid both.
> 
> bo0od writes:
>> The real issue it caused guix to freeze for like not less than 2+
>> hours and i couldnt do anything with the distro until guix cut out
>> the build/upgradation by itself.
> 
> Take a look at (and next time, attach)
> 
>   $ bzless 
>   /var/log/guix/drvs/5a/8xxi15g20iqr78daw3w1c7xyqmmd1k-vigra-1.11.1.drv.bz2
> 
> the log file mentioned in the error message.  You'll probably find the 
> string ‘Killed’ near the end.  If you haven't rebooted yet,
> 
>   $ grep oom /proc/vmstat
> 
> will probably return something non-zero.
> 
> If so: you ran out of memory while building a heavy package.  This 
> causes your system to become unresponsive whilst it tries to postpone 
> that for as long as possible.  This is a fact of Linux.
> 
> You can try to work around it by adding RAM, passing ‘-{M,c}1’ to the 
> guix command that failed, and/or enabling swap, but the root cause is 
> you simply don't have enough memory to build this package at its default 
> settings.
> 
> Or, you can make sure you download a substitute instead of trying to 
> build everything locally.  At the time of writing (commit d14f213) 
> there's a libreoffice substitute on ci.guix.gnu.org.  Are substitutes 
> configured and enabled?
> 
> Kind regards,
> 
> T G-R

[bzlessvigra.txt (text/plain, attachment)]

Message #34 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: bo0od <bo0od <at> riseup.net>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix becomes unresponsive while building the 'vigra'
 package
Date: Tue, 13 Apr 2021 13:35:56 -0400

On Tue, Apr 13, 2021 at 11:03:50AM +0000, bo0od wrote:
> 4GB DDR3 rams, i7 4th generation , 20GB for Guix about 9GB swap
> 
> If this is not enough to install simple common used packages like
> libreoffice or onionshare..etc then this is big issue if guix considered to
> be targeting average users.
> 
> In Qubes distro 4GB is worthless/nothing the minimum is like 8GB and above.
> If guix is the same thing then no problem but for surely it need to be
> mentioned somewhere obvious(i didnt find it anywhere saying that).

The ideal situation is that substitutes for these packages are
available, and you don't have to build them.

Using current Guix master branch, I receive a substitute for
libreoffice. Maybe you just need to update, with `guix pull`?

In general, if you want to compile software, there will be some programs
that require a lot of computer to compile. Not even 10 GB RAM will be
enough in all cases.

Message #37 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bo0od <bo0od <at> riseup.net>
Cc: 47717 <at> debbugs.gnu.org, bug-guix <at> gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Wed, 14 Apr 2021 02:40:00 +0200

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #43 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bo0od <bo0od <at> riseup.net>, Leo Famulari <leo <at> famulari.name>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix becomes unresponsive while building the 'vigra'
 package
Date: Wed, 14 Apr 2021 04:21:44 -0400

bo0od <bo0od <at> riseup.net> writes:

>  > What kind of computer are you using? Are you using swap?
>
> 4GB DDR3 rams, i7 4th generation , 20GB for Guix about 9GB swap

For the record: I don't use binary substitutes at all, and I build my
GNOME system plus IceCat locally, using Guix, on a modest Thinkpad X200
with 4GB of RAM and 8GB of swap, all while running a GNOME session with
Emacs.

I can build _most_ (but not all) packages while running IceCat.
However, some builds, e.g. IceCat and WebKitGTK, require too much memory
to build while simultaneously running a modern web browser.

I haven't tried to build Libreoffice recently, but I did so regularly a
few years ago.

* * *

I suspect that your problem is that you have too many CPUs relative to
your relatively modest 4GB of RAM.  The more CPUs you have, the more
compilers will be run concurrently (by default), and the more RAM you
will need.

In my case, I have only 2 CPUs on my system, so I have only two
instances of GCC (or whatever compiler) running at any given time.

It might help to pass --cores=2 (or perhaps even --cores=1) to
guix-daemon, which should hopefully be honored by the build systems of
most of our packages, but probably not all (bug reports welcome).

On a Guix system, you can arrange for this in your OS config with
something like the following (untested):

__ (modify-services %desktop-services
____ (guix-service-type config =>
_______________________ (guix-configuration
_________________________ (inherit config)
_________________________ (extra-options '("--cores=2")))))

       Mark

Message #46 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: bo0od <bo0od <at> riseup.net>
To: Leo Famulari <leo <at> famulari.name>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix becomes unresponsive while building the 'vigra'
 package
Date: Wed, 14 Apr 2021 16:06:47 +0000

> The ideal situation is that substitutes for these packages are
> available, and you don't have to build them.

Does that mean almost every user who gonna use guix system which will 
eventually fall into the same issue you gonna tell oh sorry default 
doesnt help do 123? we need solutions for the future, solutions for the 
coming users not workarounds.

> In general, if you want to compile software, there will be some programs
> that require a lot of computer to compile. Not even 10 GB RAM will be
> enough in all cases.

Im doing what guix default doing, didnt play with anything and if the 
default may require more than 10GB of rams this distro wont reach the 
sunlight for the end, Because even if it reaches he gonna delete it 
later due to issues similar to this one.

Check this:

https://forums.whonix.org/t/constrained-system-resources-program-starter-wrapper/10914

maybe something like this if guix devs done will solve alot of headaches.

Leo Famulari:
> On Tue, Apr 13, 2021 at 11:03:50AM +0000, bo0od wrote:
>> 4GB DDR3 rams, i7 4th generation , 20GB for Guix about 9GB swap
>>
>> If this is not enough to install simple common used packages like
>> libreoffice or onionshare..etc then this is big issue if guix considered to
>> be targeting average users.
>>
>> In Qubes distro 4GB is worthless/nothing the minimum is like 8GB and above.
>> If guix is the same thing then no problem but for surely it need to be
>> mentioned somewhere obvious(i didnt find it anywhere saying that).
> 
> The ideal situation is that substitutes for these packages are
> available, and you don't have to build them.
> 
> Using current Guix master branch, I receive a substitute for
> libreoffice. Maybe you just need to update, with `guix pull`?
> 
> In general, if you want to compile software, there will be some programs
> that require a lot of computer to compile. Not even 10 GB RAM will be
> enough in all cases.
> 

Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bo0od <bo0od <at> riseup.net>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 47717 <at> debbugs.gnu.org, bug-guix <at> gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Wed, 14 Apr 2021 16:54:51 +0000

> 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

Message #55 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: bo0od <bo0od <at> riseup.net>
To: Mark H Weaver <mhw <at> netris.org>, Leo Famulari <leo <at> famulari.name>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix becomes unresponsive while building the 'vigra'
 package
Date: Wed, 14 Apr 2021 17:08:33 +0000

> It might help to pass --cores=2 (or perhaps even --cores=1) to
> guix-daemon, which should hopefully be honored by the build systems of
> most of our packages, but probably not all (bug reports welcome).

Thanks for the suggestion, But you know this is gonna be mouse and cat 
issue if its not fixed by default for the end user.

- No warning in the docs saying that guix not intended to be for end 
user with average pc resources (if no body willing to give solution by 
default).

- No popup telling the user your pc resources/rams (whatever) are low 
please allow the usage of substitutes for this package in order to avoid 
possible machine exhausting/freezing <- or any similar message.

...etc from similar ideas.

But leaving it to the air whenever happen it happen and user later 
discover that guix just refrigerator/freezer tool then wonder why would 
the user keep using it...

Mark H Weaver:
> bo0od <bo0od <at> riseup.net> writes:
> 
>>   > What kind of computer are you using? Are you using swap?
>>
>> 4GB DDR3 rams, i7 4th generation , 20GB for Guix about 9GB swap
> 
> For the record: I don't use binary substitutes at all, and I build my
> GNOME system plus IceCat locally, using Guix, on a modest Thinkpad X200
> with 4GB of RAM and 8GB of swap, all while running a GNOME session with
> Emacs.
> 
> I can build _most_ (but not all) packages while running IceCat.
> However, some builds, e.g. IceCat and WebKitGTK, require too much memory
> to build while simultaneously running a modern web browser.
> 
> I haven't tried to build Libreoffice recently, but I did so regularly a
> few years ago.
> 
> * * *
> 
> I suspect that your problem is that you have too many CPUs relative to
> your relatively modest 4GB of RAM.  The more CPUs you have, the more
> compilers will be run concurrently (by default), and the more RAM you
> will need.
> 
> In my case, I have only 2 CPUs on my system, so I have only two
> instances of GCC (or whatever compiler) running at any given time.
> 
> It might help to pass --cores=2 (or perhaps even --cores=1) to
> guix-daemon, which should hopefully be honored by the build systems of
> most of our packages, but probably not all (bug reports welcome).
> 
> On a Guix system, you can arrange for this in your OS config with
> something like the following (untested):
> 
> __ (modify-services %desktop-services
> ____ (guix-service-type config =>
> _______________________ (guix-configuration
> _________________________ (inherit config)
> _________________________ (extra-options '("--cores=2")))))
> 
>         Mark
> 

Message #58 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bo0od <bo0od <at> riseup.net>, Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Thu, 15 Apr 2021 15:56:33 -0400

bo0od <bo0od <at> riseup.net> writes:

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

'earlyoom' behavior is not necessarily desirable.  I, for one, have a
fairly old computer by today's standards, and sometimes I ask it to do
intensive things that are at the edge of its capabilities, such as
compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
jobs that could have completed, and thereby make it impossible for me to
continue using this old computer for development.

With that in mind, it's far from clear that 'earlyoom' should be our
default behavior.  It's good to have it as an option, though.

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

Many people are happily using it, and are quite enthusiastic about it,
so evidently it's "usable".  That doesn't imply that it's good for
everyone.  Perhaps you would prefer a more traditional distro, or one
that has had more time to mature.  If so, that's okay.

      Regards,
        Mark

Message #61 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: bo0od <bo0od <at> riseup.net>
To: Mark H Weaver <mhw <at> netris.org>, Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Fri, 16 Apr 2021 03:08:08 +0000

> Many people are happily using it, and are quite enthusiastic about it,
> so evidently it's "usable".  That doesn't imply that it's good for
> everyone.  Perhaps you would prefer a more traditional distro, or one
> that has had more time to mature.  If so, that's okay.

I can say that on almost any dying distro like slackware or so. But we 
need to overcome the issues which are leading to dead projects/distros.

The above issue is one of them if left without solution.

Mark H Weaver:
> bo0od <bo0od <at> riseup.net> writes:
> 
>>   > 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.
> 
> 'earlyoom' behavior is not necessarily desirable.  I, for one, have a
> fairly old computer by today's standards, and sometimes I ask it to do
> intensive things that are at the edge of its capabilities, such as
> compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
> jobs that could have completed, and thereby make it impossible for me to
> continue using this old computer for development.
> 
> With that in mind, it's far from clear that 'earlyoom' should be our
> default behavior.  It's good to have it as an option, though.
> 
>>   > 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.
> 
> Many people are happily using it, and are quite enthusiastic about it,
> so evidently it's "usable".  That doesn't imply that it's good for
> everyone.  Perhaps you would prefer a more traditional distro, or one
> that has had more time to mature.  If so, that's okay.
> 
>        Regards,
>          Mark
> 

Message #64 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: bo0od <bo0od <at> riseup.net>, Tobias Geerinckx-Rice <me <at> tobias.gr>,
 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Tue, 20 Apr 2021 21:35:34 -0400

Hi,

Mark H Weaver <mhw <at> netris.org> writes:

> bo0od <bo0od <at> riseup.net> writes:
>
>>  > 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.
>
> 'earlyoom' behavior is not necessarily desirable.  I, for one, have a
> fairly old computer by today's standards, and sometimes I ask it to do
> intensive things that are at the edge of its capabilities, such as
> compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
> jobs that could have completed, and thereby make it impossible for me to
> continue using this old computer for development.
>
> With that in mind, it's far from clear that 'earlyoom' should be our
> default behavior.  It's good to have it as an option, though.

Earlyoom's default config is to only kills processes when both the
physical memory *and* the swap have been used by more than 90%; in such
as serious resource depletion situation, that usually mean having to
hard reset the machine, or waiting one night not knowing if it'll be
done doing whatever it's doing the next morning (probably getting OOM'd
anyway by the kernel, Linux).

>>  > 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.
>
> Many people are happily using it, and are quite enthusiastic about it,
> so evidently it's "usable".  That doesn't imply that it's good for
> everyone.  Perhaps you would prefer a more traditional distro, or one
> that has had more time to mature.  If so, that's okay.

My 2 cents here is that earlyoom makes Guix System more usable on dated
hardware than Linux's default OOM behavior; from my experience of using
it on a 4 GiB RAM 2010-era laptop for a good while.

I personally would see it a good option for our users to have it on by
default *if* we could manage to connect Earlyoom's notification system
with the desktop (via D-Bus, I think it supports that), so that when a
process is killed, the users has some feedback about it (the stock Linux
OOMK is sure to not let you wondering what's going on -- everything
stops to a crawl, and your hard drive gets thrashed).

Maxim

Message #67 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: bo0od <bo0od <at> riseup.net>, Tobias Geerinckx-Rice <me <at> tobias.gr>,
 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Thu, 22 Apr 2021 14:34:22 -0400

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> 'earlyoom' behavior is not necessarily desirable.  I, for one, have a
>> fairly old computer by today's standards, and sometimes I ask it to do
>> intensive things that are at the edge of its capabilities, such as
>> compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
>> jobs that could have completed, and thereby make it impossible for me to
>> continue using this old computer for development.
>>
>> With that in mind, it's far from clear that 'earlyoom' should be our
>> default behavior.  It's good to have it as an option, though.
>
> Earlyoom's default config is to only kills processes when both the
> physical memory *and* the swap have been used by more than 90%; in such
> as serious resource depletion situation, that usually mean having to
> hard reset the machine, or waiting one night not knowing if it'll be
> done doing whatever it's doing the next morning (probably getting OOM'd
> anyway by the kernel, Linux).
[...]
> My 2 cents here is that earlyoom makes Guix System more usable on dated
> hardware than Linux's default OOM behavior; from my experience of using
> it on a 4 GiB RAM 2010-era laptop for a good while.

Okay, I trust your judgment on this.  I haven't tried 'earlyoom' myself.
Moreover, my use case is very unusual, and so it doesn't make sense to
choose a default behavior based on my needs.

So, I've changed my mind.  Thanks for talking me through it.

> I personally would see it a good option for our users to have it on by
> default *if* we could manage to connect Earlyoom's notification system
> with the desktop (via D-Bus, I think it supports that), so that when a
> process is killed, the users has some feedback about it (the stock Linux
> OOMK is sure to not let you wondering what's going on -- everything
> stops to a crawl, and your hard drive gets thrashed).

That sounds excellent, if it can be done.  Otherwise, it might still
make sense to have 'earlyoom' on by default in Guix.  I'll leave it to
others to decide.

      Thanks,
        Mark

-- 
Support Richard Stallman against the vicious misinformation campaign
against him and the FSF.  See <https://stallmansupport.org> for more.

Message #70 received at 47717 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Mark H Weaver <mhw <at> netris.org>
Cc: bo0od <bo0od <at> riseup.net>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 47717 <at> debbugs.gnu.org
Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there
 is package build failure
Date: Sun, 25 Apr 2021 11:14:04 +0300

[Message part 1 (text/plain, inline)]

On Thu, Apr 22, 2021 at 02:34:22PM -0400, Mark H Weaver wrote:
> Hi Maxim,
> 
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> 
> > Mark H Weaver <mhw <at> netris.org> writes:
> >
> >> 'earlyoom' behavior is not necessarily desirable.  I, for one, have a
> >> fairly old computer by today's standards, and sometimes I ask it to do
> >> intensive things that are at the edge of its capabilities, such as
> >> compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
> >> jobs that could have completed, and thereby make it impossible for me to
> >> continue using this old computer for development.
> >>
> >> With that in mind, it's far from clear that 'earlyoom' should be our
> >> default behavior.  It's good to have it as an option, though.
> >
> > Earlyoom's default config is to only kills processes when both the
> > physical memory *and* the swap have been used by more than 90%; in such
> > as serious resource depletion situation, that usually mean having to
> > hard reset the machine, or waiting one night not knowing if it'll be
> > done doing whatever it's doing the next morning (probably getting OOM'd
> > anyway by the kernel, Linux).
> [...]
> > My 2 cents here is that earlyoom makes Guix System more usable on dated
> > hardware than Linux's default OOM behavior; from my experience of using
> > it on a 4 GiB RAM 2010-era laptop for a good while.
> 
> Okay, I trust your judgment on this.  I haven't tried 'earlyoom' myself.
> Moreover, my use case is very unusual, and so it doesn't make sense to
> choose a default behavior based on my needs.
> 
> So, I've changed my mind.  Thanks for talking me through it.
> 
> > I personally would see it a good option for our users to have it on by
> > default *if* we could manage to connect Earlyoom's notification system
> > with the desktop (via D-Bus, I think it supports that), so that when a
> > process is killed, the users has some feedback about it (the stock Linux
> > OOMK is sure to not let you wondering what's going on -- everything
> > stops to a crawl, and your hard drive gets thrashed).
> 
> That sounds excellent, if it can be done.  Otherwise, it might still
> make sense to have 'earlyoom' on by default in Guix.  I'll leave it to
> others to decide.
> 
>       Thanks,
>         Mark

FWIW I setup OOM so that it would specifically kill build processes or
icecat but  not my desktop.

           (service earlyoom-service-type
                    (earlyoom-configuration
                      (prefer-regexp "(cc1(plus)?|.rustc-real|ghc|Web Content)")
                      (avoid-regexp "enlightenment")))

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.