Avoid system freezes by using earlyoom (with D-Bus notifications)

  • Open
  • quality assurance status badge
Details
7 participants
  • bo0od
  • Efraim Flashner
  • Leo Famulari
  • Maxim Cournoyer
  • Tobias Geerinckx-Rice
  • Mark H Weaver
  • raingloom
Owner
unassigned
Submitted by
bo0od
Severity
normal
B
B
bo0od wrote on 12 Apr 2021 07:39
guix outrageously exhaust itself (freeze) when there is package build failure
(address . bug-guix@gnu.org)
eadb0b91-be87-854e-8bb0-29932a2c20fd@riseup.net
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.
Attachment: guixfreeze.png
Attachment: guixfreeze.txt
L
L
Leo Famulari wrote on 12 Apr 2021 20:01
(no subject)
(address . control@debbugs.gnu.org)
YHSLBUZPkLjy1k1W@jasmine.lan
retitle 47717 guix becomes unresponsive while building the 'vigra' package
L
L
Leo Famulari wrote on 12 Apr 2021 20:04
Re: bug#47717: guix becomes unresponsive while building the 'vigra' package
(name . bo0od)(address . bo0od@riseup.net)(address . 47717@debbugs.gnu.org)
YHSLqEeb6yRril23@jasmine.lan
On Mon, Apr 12, 2021 at 05:39:11AM +0000, bo0od wrote:
Toggle quote (7 lines)
> 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.

[...]

Toggle quote (5 lines)
> 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...
T
T
Tobias Geerinckx-Rice wrote on 12 Apr 2021 20:41
Re: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
(name . bo0od)(address . bo0od@riseup.net)
87fszvfirn.fsf@nckx
Hi bo0od,

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

bo0od writes:
Toggle quote (6 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYHSUPA0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15FPsBAICzy+QIu1HrbeXT4japfxxsQCB0izHzI0VuILPS
EuNhAQDjxW/r1qrmlEJ7DPrvZTQxvdO9jTk2gGhakZI5oXG7DQ==
=pzrT
-----END PGP SIGNATURE-----

R
R
raingloom wrote on 13 Apr 2021 00:59
(name . Tobias Geerinckx-Rice via Bug reports for GNU Guix)(address . bug-guix@gnu.org)
20210413005934.2613cb57@riseup.net
On Mon, 12 Apr 2021 20:41:00 +0200
Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org>
wrote:

Toggle quote (42 lines)
> 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.
B
B
bo0od wrote on 13 Apr 2021 13:03
Re: bug#47717: guix becomes unresponsive while building the 'vigra' package
(name . Leo Famulari)(address . leo@famulari.name)(address . 47717@debbugs.gnu.org)
73e4e511-b66a-e62b-7ce8-bb6029ef0d2c@riseup.net
Toggle quote (2 lines)
> 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).


Toggle quote (23 lines)
> 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...
>
B
B
bo0od wrote on 13 Apr 2021 13:34
Re: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
0dbc191f-f567-01f0-b20e-67c00fd28937@riseup.net
Toggle quote (1 lines)
> 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.



Toggle quote (38 lines)
> 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
Attachment: bzlessvigra.txt
L
L
Leo Famulari wrote on 13 Apr 2021 19:35
Re: bug#47717: guix becomes unresponsive while building the 'vigra' package
(name . bo0od)(address . bo0od@riseup.net)(address . 47717@debbugs.gnu.org)
YHXWfNAWojS67oXE@jasmine.lan
On Tue, Apr 13, 2021 at 11:03:50AM +0000, bo0od wrote:
Toggle quote (10 lines)
> 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.
T
T
Tobias Geerinckx-Rice wrote on 14 Apr 2021 02:40
Re: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
(name . bo0od)(address . bo0od@riseup.net)
87czuxem1r.fsf@nckx
bo0od writes:
Toggle quote (2 lines)
> 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.

Toggle quote (4 lines)
> /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.

Toggle quote (2 lines)
> 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.

Toggle quote (2 lines)
> 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.

Toggle quote (4 lines)
> 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?

Toggle quote (4 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYHY54A0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW155hMBAOMLsD5jKPaJy+wAQSRLmKR76BWtH8VJJ6kC/0iu
w0AuAQD2+RBsxIkQfMtLtrql5bJCBnnS3QOmkAe9UkFJ+VRZAA==
=Ms1B
-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 14 Apr 2021 10:21
Re: bug#47717: guix becomes unresponsive while building the 'vigra' package
(address . 47717@debbugs.gnu.org)
87im4pqnrg.fsf@netris.org
bo0od <bo0od@riseup.net> writes:

Toggle quote (4 lines)
> > 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
B
B
bo0od wrote on 14 Apr 2021 18:06
(name . Leo Famulari)(address . leo@famulari.name)(address . 47717@debbugs.gnu.org)
96f44221-6c8d-3902-c8fb-2d4fe70bfb48@riseup.net
Toggle quote (1 lines)
> 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:


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

Leo Famulari:
Toggle quote (21 lines)
> 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.
>
B
B
bo0od wrote on 14 Apr 2021 18:54
Re: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
4e1f8d67-2329-6ba1-4e21-9ec978de3cb3@riseup.net
Toggle quote (1 lines)
> 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:


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:


> 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:
Toggle quote (56 lines)
> 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
B
B
bo0od wrote on 14 Apr 2021 19:08
Re: bug#47717: guix becomes unresponsive while building the 'vigra' package
(address . 47717@debbugs.gnu.org)
660cd94a-1983-a59d-96d5-dd79794b2460@riseup.net
Toggle quote (1 lines)
> 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:
Toggle quote (43 lines)
> bo0od <bo0od@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
>
M
M
Mark H Weaver wrote on 15 Apr 2021 21:56
Re: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
(address . 47717@debbugs.gnu.org)
878s5jiann.fsf@netris.org
bo0od <bo0od@riseup.net> writes:

Toggle quote (7 lines)
> > 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.

Toggle quote (10 lines)
> > 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
B
B
bo0od wrote on 16 Apr 2021 05:08
(address . 47717@debbugs.gnu.org)
ae83cce7-fcde-c0d9-3a72-052615fb3d25@riseup.net
Toggle quote (1 lines)
> 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:
Toggle quote (37 lines)
> bo0od <bo0od@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
>
M
M
Maxim Cournoyer wrote on 21 Apr 2021 03:35
(name . Mark H Weaver)(address . mhw@netris.org)
871rb4fmhl.fsf@gmail.com
Hi,

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

Toggle quote (19 lines)
> bo0od <bo0od@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).

Toggle quote (15 lines)
>> > 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
M
M
Mark H Weaver wrote on 22 Apr 2021 20:34
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87k0ouyxpy.fsf@netris.org
Hi Maxim,

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

Toggle quote (18 lines)
> Mark H Weaver <mhw@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).
[...]
Toggle quote (4 lines)
> 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.

Toggle quote (7 lines)
> 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.
E
E
Efraim Flashner wrote on 25 Apr 2021 10:14
(name . Mark H Weaver)(address . mhw@netris.org)
YIUkzDS43Ez84hWL@3900XT
On Thu, Apr 22, 2021 at 02:34:22PM -0400, Mark H Weaver wrote:
Toggle quote (47 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
> > Mark H Weaver <mhw@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@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
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmCFJMoACgkQQarn3Mo9
g1EPAQ//ZMvZNOls+zMILSUUbQte/tsnOEpW1FBqpTQJddZDtgOVCQEzR9LjfNSF
mxcyHVyTRvXBbkeb06RuMTtWzFGJwXPBQitXytDt/5J5UHHQ+1Ew86MOMNfluxQ2
j1Mucqz8iRMu1GkjeTKpp5obYwHo0jq6D8h31dUIILwXwB2tLov7jaQ1ZQQhux8Q
Jnf/wP4RoV2AQLhYtoXh8dOOsYDJg7Ii9BO8a1Frh4hHaeBR94ZLzodxdRrE4FHM
HNQOuOkYaSjU1Z/upc3C/IbkPmJ7RwgzFrY/raR8N235qlARRvQeGMCtWVacpMEA
FYySbwHSh7uHf1zfpx2eU4a2U4KYSywLq9RI/w01VwBQJigVixbF3oru9pQf7cK6
Chp50Oq7yOdm8tS2d0DCIGllrTLPKOjuFElNiu9n6AwHhBThEb1QmByzGDbM7tR4
diExmDhMCYViM25qKjvYvJ7rKPKesBz3Xe30A43Ah8jmbznQ9ykmr2CuyCmB0KgJ
E/wxF9ByRA1ddEFZ6kvNKBKuXJ0pmuLvyKoDV3nH/1TvdJOq7ep4Gsmgl0ZgLlMc
72jlc3cfMOwFXa6I9u/g5n1h9OTPSsDP5MOoz3cqjR2AYn2bmtjjVzKxRbVwPZFa
3WxJKM3TpPfVLFEoadKN2ImlRaKf6six+gQMhPnP4jTo0E2OtKM=
=JyLY
-----END PGP SIGNATURE-----


M
M
Maxim Cournoyer wrote on 18 Mar 2022 04:09
control message for bug #47717
(address . control@debbugs.gnu.org)
8735jg6jok.fsf@gmail.com
retitle 47717 Avoid system freezes by using earlyoom (with D-Bus notifications)
quit
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 47717@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 47717
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch