From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 17D15138334 for ; Tue, 30 Oct 2018 12:30:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 11D65E0934; Tue, 30 Oct 2018 12:30:07 +0000 (UTC) Received: from asav21.altibox.net (asav21.altibox.net [109.247.116.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6E5B8E0929 for ; Tue, 30 Oct 2018 12:30:06 +0000 (UTC) Received: from postfix-relay.alstadheim.priv.no (148-252-110.181.3p.ntebredband.no [148.252.110.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon.alstadheim@ntebb.no) by asav21.altibox.net (Postfix) with ESMTPSA id 82D148017B for ; Tue, 30 Oct 2018 13:30:04 +0100 (CET) X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no Received: from smtps.alstadheim.priv.no (localhost [127.0.0.1]) by postfix-relay.alstadheim.priv.no (Postfix) with ESMTP id D83E1624E8A4 for ; Tue, 30 Oct 2018 13:30:01 +0100 (CET) Received: from [192.168.2.201] (unknown [192.168.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hakon) by smtps.alstadheim.priv.no (Postfix) with ESMTPSA id 547BF244BC05 for ; Tue, 30 Oct 2018 13:30:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alstadheim.priv.no; s=smtp; t=1540902601; bh=7+7AxI8sZjWct8fvq6+GCEufbQpX6lp0ak/P5VMV07s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=M6wNqd+aUjmXGgxKrzu3298gDY0ypmDsARo/f8h+PE12MfXGMVIu9yYfQojPfwUcS IAeFeIustGWViRwWoIMRY/QCqVuPPnHQ2XFRL0Ee3qgA+L+lOT5JlikQ7z4RDDkCTK AjNGbZsSh71SEZ6BOps6DQTFUIzgnhOK7lTZ877c= Subject: Re: [gentoo-user] portage sandbox path-depth limit ? To: gentoo-user@lists.gentoo.org References: <5e547720-d07f-85e7-0c35-4216542e2716@alstadheim.priv.no> <5797526.9VfBFksnok@dell_xps> From: =?UTF-8?Q?H=c3=a5kon_Alstadheim?= Message-ID: <65e0913f-22bf-2df7-6f24-f8e51296de1a@alstadheim.priv.no> Date: Tue, 30 Oct 2018 13:29:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <5797526.9VfBFksnok@dell_xps> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=ZI75Z0zb c=1 sm=1 tr=0 a=nKBCZnvRSnKQV5aoQPnoIA==:117 a=nKBCZnvRSnKQV5aoQPnoIA==:17 a=IkcTkHD0fZMA:10 a=smKx5t2vBNcA:10 a=IxE-6dkX3LsVirIN1-YA:9 a=QEXdDO2ut3YA:10 X-Archives-Salt: c7ce703f-f4e6-4a99-89f5-d19a6e125e7e X-Archives-Hash: 2cd5c6180f254948b365351a0949f357 Den 30. okt. 2018 10:01, skrev Mick: > On Tuesday, 30 October 2018 06:30:23 GMT Håkon Alstadheim wrote: >> I'm having fun enabling "test" in FEATURES on my gentoo-desktop. One >> interesting failure, that brings to mind build failures I have had in >> the past: >> >> Building sys-apps/mlocate-0.26-r2, I get >> >> 43: updatedb: Very deep hierarchy FAILED >> (updatedb.at:261) >> >> Trying to reproduce, as root I do "make check" in the work/mlocate-0.26/ >> , and the test passes. >> >> 43: updatedb: Very deep hierarchy ok >> >> I'd really like to get to the bottom of this, as I believe it must have >> the same root-cause as issues I have had compiling large packages such >> as firefox. >> >> Re-running both the emerge and the make check, I get the same results. >> emerge fails, make check succeeds. I made a local copy of the ebuild and >> inserted a "ulimit -a" in pre_src_test. >> >> ulimit from root-shell: >> >> # ulimit -a >> core file size (blocks, -c) unlimited >> data seg size (kbytes, -d) unlimited >> scheduling priority (-e) 0 >> file size (blocks, -f) unlimited >> pending signals (-i) 59958 >> max locked memory (kbytes, -l) 16384 >> max memory size (kbytes, -m) unlimited >> open files (-n) 1024 >> pipe size (512 bytes, -p) 8 >> POSIX message queues (bytes, -q) 819200 >> real-time priority (-r) 0 >> stack size (kbytes, -s) 8192 >> cpu time (seconds, -t) unlimited >> max user processes (-u) 10000 >> virtual memory (kbytes, -v) unlimited >> file locks (-x) unlimited >> >> ulimit from emerge: >>>>> Source compiled. >> core file size (blocks, -c) unlimited >> data seg size (kbytes, -d) unlimited >> scheduling priority (-e) 0 >> file size (blocks, -f) unlimited >> pending signals (-i) 59958 >> max locked memory (kbytes, -l) 16384 >> max memory size (kbytes, -m) unlimited >> open files (-n) 1024 >> pipe size (512 bytes, -p) 8 >> POSIX message queues (bytes, -q) 819200 >> real-time priority (-r) 0 >> stack size (kbytes, -s) 9788 >> cpu time (seconds, -t) unlimited >> max user processes (-u) 10000 >> virtual memory (kbytes, -v) unlimited >> file locks (-x) unlimited >> >>>>> Test phase: sys-apps/mlocate-0.26-r2 >> I have plenty of space in my portage temp directory (/pt): >> >> # df -hT ./ >> Filsystem Type Størrelse Brukt Tilgj. Bruk% Montert på >> /dev/xvdc ext4 163G 8,0G 147G 6% /pt >> >> Portage temp is at /pt due to the earlier mentioned issues with firefox. >> >> At my wits end here. Anyone ? > I have not looked or used the test FEATURES of portage, but have also noticed > over time certain packages fail to build on machines with low RAM. As low > here I consider anything less than 4G. It seems each thread is now consuming > so much memory they cumulatively use up all RAM available and then start > swapping endlessly until the compilation invariably fails. Increasingly more > and more packages have been suffering from this, the last two I noticed are > qtwebkit and qtwebengine. > > My solution has been to create a package.env file in which I specify MAKEOPTS > limiting the number of jobs and average load for any of these packages which > chew up all the RAM. Memory should not be a problem here. Fails with only that one emerge running, succeeds if run directly as root, or with FEATURES="-sandbox -usersandbox". Memory is >14GB: # vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st  3  4  28416 6904608 174112 4616144    0    0    65   266   13    4 10  2 84  4  0