From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 14 12:55:08 2021 Received: (at submit) by debbugs.gnu.org; 14 Apr 2021 16:55:08 +0000 Received: from localhost ([127.0.0.1]:35587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWinE-00037z-5N for submit@debbugs.gnu.org; Wed, 14 Apr 2021 12:55:08 -0400 Received: from lists.gnu.org ([209.51.188.17]:60652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWin7-00037E-PE for submit@debbugs.gnu.org; Wed, 14 Apr 2021 12:55:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48128) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWin7-0005XV-C8 for bug-guix@gnu.org; Wed, 14 Apr 2021 12:55:01 -0400 Received: from mx1.riseup.net ([198.252.153.129]:34072) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWin4-0004n9-Gw for bug-guix@gnu.org; Wed, 14 Apr 2021 12:55:00 -0400 Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4FL7r01Jj1zDs7m; Wed, 14 Apr 2021 09:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1618419296; bh=3Xjt1v9HmDSC4hUS9wR3uBLUg+1kMFH+777OlY+3kqA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=H8RNE1+MfPz9kRWu7n08S/d++AOVFEMn1gAFIDsm8ooMEntv1YdTAJkqaD7N36m0C fItESfgsxcPLBp2ReCqPlsYGZxlgpQCs2qiEAj/BUd/ExjaR13KHbbLKyEYGLgkrJq 0WySw3RkBAOd/DCgAm4ITNiDiRPTjaL8EtA71HlY= X-Riseup-User-ID: 47F74486D8A9DEEF4BF154095FE70A9A9D4A12BE67BD27E754091E6F80B32366 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4FL7qy3GXMz5w5X; Wed, 14 Apr 2021 09:54:54 -0700 (PDT) Subject: Re: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure To: Tobias Geerinckx-Rice References: <87fszvfirn.fsf@nckx> <0dbc191f-f567-01f0-b20e-67c00fd28937@riseup.net> <87czuxem1r.fsf@nckx> From: bo0od Message-ID: <4e1f8d67-2329-6ba1-4e21-9ec978de3cb3@riseup.net> Date: Wed, 14 Apr 2021 16:54:51 +0000 MIME-Version: 1.0 In-Reply-To: <87czuxem1r.fsf@nckx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=198.252.153.129; envelope-from=bo0od@riseup.net; helo=mx1.riseup.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: 47717@debbugs.gnu.org, bug-guix@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) > 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 > 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