| 1 |
On Tue, 30 Oct 2018 13:29:59 +0100 Håkon Alstadheim wrote: |
| 2 |
> |
| 3 |
> Den 30. okt. 2018 10:01, skrev Mick: |
| 4 |
> > On Tuesday, 30 October 2018 06:30:23 GMT Håkon Alstadheim wrote: |
| 5 |
> >> I'm having fun enabling "test" in FEATURES on my gentoo-desktop. One |
| 6 |
> >> interesting failure, that brings to mind build failures I have had in |
| 7 |
> >> the past: |
| 8 |
> >> |
| 9 |
> >> Building sys-apps/mlocate-0.26-r2, I get |
| 10 |
> >> |
| 11 |
> >> 43: updatedb: Very deep hierarchy FAILED |
| 12 |
> >> (updatedb.at:261) |
| 13 |
> >> |
| 14 |
> >> Trying to reproduce, as root I do "make check" in the work/mlocate-0.26/ |
| 15 |
> >> , and the test passes. |
| 16 |
> >> |
| 17 |
> >> 43: updatedb: Very deep hierarchy ok |
| 18 |
> >> |
| 19 |
> >> I'd really like to get to the bottom of this, as I believe it must have |
| 20 |
> >> the same root-cause as issues I have had compiling large packages such |
| 21 |
> >> as firefox. |
| 22 |
> >> |
| 23 |
> >> Re-running both the emerge and the make check, I get the same results. |
| 24 |
> >> emerge fails, make check succeeds. I made a local copy of the ebuild and |
| 25 |
> >> inserted a "ulimit -a" in pre_src_test. |
| 26 |
> >> |
| 27 |
> >> ulimit from root-shell: |
| 28 |
> >> |
| 29 |
> >> # ulimit -a |
| 30 |
> >> core file size (blocks, -c) unlimited |
| 31 |
> >> data seg size (kbytes, -d) unlimited |
| 32 |
> >> scheduling priority (-e) 0 |
| 33 |
> >> file size (blocks, -f) unlimited |
| 34 |
> >> pending signals (-i) 59958 |
| 35 |
> >> max locked memory (kbytes, -l) 16384 |
| 36 |
> >> max memory size (kbytes, -m) unlimited |
| 37 |
> >> open files (-n) 1024 |
| 38 |
> >> pipe size (512 bytes, -p) 8 |
| 39 |
> >> POSIX message queues (bytes, -q) 819200 |
| 40 |
> >> real-time priority (-r) 0 |
| 41 |
> >> stack size (kbytes, -s) 8192 |
| 42 |
> >> cpu time (seconds, -t) unlimited |
| 43 |
> >> max user processes (-u) 10000 |
| 44 |
> >> virtual memory (kbytes, -v) unlimited |
| 45 |
> >> file locks (-x) unlimited |
| 46 |
> >> |
| 47 |
> >> ulimit from emerge: |
| 48 |
> >>>>> Source compiled. |
| 49 |
> >> core file size (blocks, -c) unlimited |
| 50 |
> >> data seg size (kbytes, -d) unlimited |
| 51 |
> >> scheduling priority (-e) 0 |
| 52 |
> >> file size (blocks, -f) unlimited |
| 53 |
> >> pending signals (-i) 59958 |
| 54 |
> >> max locked memory (kbytes, -l) 16384 |
| 55 |
> >> max memory size (kbytes, -m) unlimited |
| 56 |
> >> open files (-n) 1024 |
| 57 |
> >> pipe size (512 bytes, -p) 8 |
| 58 |
> >> POSIX message queues (bytes, -q) 819200 |
| 59 |
> >> real-time priority (-r) 0 |
| 60 |
> >> stack size (kbytes, -s) 9788 |
| 61 |
> >> cpu time (seconds, -t) unlimited |
| 62 |
> >> max user processes (-u) 10000 |
| 63 |
> >> virtual memory (kbytes, -v) unlimited |
| 64 |
> >> file locks (-x) unlimited |
| 65 |
> >> |
| 66 |
> >>>>> Test phase: sys-apps/mlocate-0.26-r2 |
| 67 |
> >> I have plenty of space in my portage temp directory (/pt): |
| 68 |
> >> |
| 69 |
> >> # df -hT ./ |
| 70 |
> >> Filsystem Type Størrelse Brukt Tilgj. Bruk% Montert på |
| 71 |
> >> /dev/xvdc ext4 163G 8,0G 147G 6% /pt |
| 72 |
> >> |
| 73 |
> >> Portage temp is at /pt due to the earlier mentioned issues with firefox. |
| 74 |
> >> |
| 75 |
> >> At my wits end here. Anyone ? |
| 76 |
> > I have not looked or used the test FEATURES of portage, but have also noticed |
| 77 |
> > over time certain packages fail to build on machines with low RAM. As low |
| 78 |
> > here I consider anything less than 4G. It seems each thread is now consuming |
| 79 |
> > so much memory they cumulatively use up all RAM available and then start |
| 80 |
> > swapping endlessly until the compilation invariably fails. Increasingly more |
| 81 |
> > and more packages have been suffering from this, the last two I noticed are |
| 82 |
> > qtwebkit and qtwebengine. |
| 83 |
> > |
| 84 |
> > My solution has been to create a package.env file in which I specify MAKEOPTS |
| 85 |
> > limiting the number of jobs and average load for any of these packages which |
| 86 |
> > chew up all the RAM. |
| 87 |
> Memory should not be a problem here. Fails with only that one emerge |
| 88 |
> running, |
| 89 |
> succeeds if run directly as root, or with FEATURES="-sandbox -usersandbox". |
| 90 |
> |
| 91 |
> Memory is >14GB: |
| 92 |
> # vmstat |
| 93 |
> procs -----------memory---------- ---swap-- -----io---- -system-- |
| 94 |
> ------cpu----- |
| 95 |
> r b swpd free buff cache si so bi bo in cs us sy |
| 96 |
> id wa st |
| 97 |
> 3 4 28416 6904608 174112 4616144 0 0 65 266 13 4 10 |
| 98 |
> 2 84 4 0 |
| 99 |
|
| 100 |
It is possible that you hit directory loop. What lstree says on |
| 101 |
that dir? Anyway, report this to sandbox devs. |
| 102 |
|
| 103 |
Best regards, |
| 104 |
Andrew Savchenko |
Archives