From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id iMjwDmvCgWAFsgAAgWs5BA (envelope-from ) for ; Thu, 22 Apr 2021 20:37:31 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id WLGlCmvCgWCHLgAAB5/wlQ (envelope-from ) for ; Thu, 22 Apr 2021 18:37:31 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 889CE18347 for ; Thu, 22 Apr 2021 20:37:30 +0200 (CEST) Received: from localhost ([::1]:41586 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZeCe-0001Q2-5a for larch@yhetil.org; Thu, 22 Apr 2021 14:37:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZeCE-0001Pr-Uu for bug-guix@gnu.org; Thu, 22 Apr 2021 14:37:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52192) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lZeCE-0003UC-EK for bug-guix@gnu.org; Thu, 22 Apr 2021 14:37:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lZeCE-0000M6-3h for bug-guix@gnu.org; Thu, 22 Apr 2021 14:37:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 22 Apr 2021 18:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47717 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Received: via spool by 47717-submit@debbugs.gnu.org id=B47717.16191165791280 (code B ref 47717); Thu, 22 Apr 2021 18:37:02 +0000 Received: (at 47717) by debbugs.gnu.org; 22 Apr 2021 18:36:19 +0000 Received: from localhost ([127.0.0.1]:35500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lZeBX-0000KY-Fv for submit@debbugs.gnu.org; Thu, 22 Apr 2021 14:36:19 -0400 Received: from world.peace.net ([64.112.178.59]:55774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lZeBV-0000KI-TA for 47717@debbugs.gnu.org; Thu, 22 Apr 2021 14:36:18 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZeBO-00052l-Ce; Thu, 22 Apr 2021 14:36:10 -0400 From: Mark H Weaver In-Reply-To: <871rb4fmhl.fsf@gmail.com> References: <87fszvfirn.fsf@nckx> <0dbc191f-f567-01f0-b20e-67c00fd28937@riseup.net> <87czuxem1r.fsf@nckx> <4e1f8d67-2329-6ba1-4e21-9ec978de3cb3@riseup.net> <878s5jiann.fsf@netris.org> <871rb4fmhl.fsf@gmail.com> Date: Thu, 22 Apr 2021 14:34:22 -0400 Message-ID: <87k0ouyxpy.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bo0od , 47717@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619116650; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post; bh=64ufj/ArGYqWzeuBoHfORjFgBEdWKhK5qaByY6Skaao=; b=IRHfP0LupEKaDC9hNuf80giJ4O11YTPHHJzhCdLBOxC2jWWIgeTDnBE4SkBwKS9TVBFaMF GurWBuOPALhXVNfts7PgOt7u9wwrmJJYN+Oqprz6Op0/0SZhUDI2UYkZUFY+0rJkk9PdyW TvBX9JT6cblx6OKBFhBsaGCR4x2AFpFT05iI/4McQlEeyFkWietuSeXS0G1WaEyFmaDr3j uEuPvwHAWNkWDTY2FgqynMoKZcVILirbguS1/2LHeD7FexIBUAMTGke9cxEJN19kWgp+5I mWzHRUaS9/KCjAZ32YbyLsKpkXZ5X52pQgHQOK25zANVwER19w9lVV4YX1peDw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619116650; a=rsa-sha256; cv=none; b=koe5b/63ndKc9Y7gErhqKp7zt8pd6zKVRBCc9KBt6lWxzE/UDgskkP0aLhHy+SrJ9MnfXH dB2XFsFLqm7JSAvJeKEEHRiGBWPHeJ4m0h6AWWPIOlebEYO93QILsaZQuz40SnJF87F7Oo 6YweslF+hb0nN5kaG2ip6AKFHyloTn3b6qqqn/xGFaTN381zqaNJn3ByjHABWc9tVgWOt+ hcf+H34vnOegyujWkwWlm8FKtOQdpp0yfQeamFyiCIPOo0N6BKsE+zjdhBEnvKKRG5P95f vOZ4fpyAO9X1CE5cWEVQUdk5I2n+3rrmrMEWS80m1l9XEGnpy7HP5xWEl8vt1A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -2.44 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 889CE18347 X-Spam-Score: -2.44 X-Migadu-Scanner: scn0.migadu.com X-TUID: hc7XmFilLsvb Hi Maxim, Maxim Cournoyer writes: > Mark H Weaver 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 for more.