Gentoo Archives: gentoo-portage-dev

From: Joshua Kinard <kumba@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles
Date: Mon, 25 Apr 2016 00:21:32
Message-Id: 571D6304.1080004@gentoo.org
In Reply to: Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles by Zac Medico
1 On 04/24/2016 20:09, Zac Medico wrote:
2 > On 04/24/2016 04:50 PM, Joshua Kinard wrote:
3 >> On 01/18/2016 07:37, Joshua Kinard wrote:
4 >>> On 01/17/2016 15:01, Zac Medico wrote:
5 >>>> On 01/17/2016 09:06 AM, Brian Dolbec wrote:
6 >>>>>
7 >>>>> I've read in several forum posts lately about emerge not running and
8 >>>>> the problem comes down to dead emerge processes and remaining lockfiles.
9 >>>>>
10 >>>>> Perhaps we should make an emaint module to search for and fix these.
11 >>>>> It should be easy enough.
12 >>>>
13 >>>> It would be nicer if we fixed whatever issue(s) cause the emerge
14 >>>> processes to hang up. How would the emaint module distinguish a "good"
15 >>>> emerge process from a "bad" one? I suppose you could strace it to see if
16 >>>> it has any activity.
17 >>>>
18 >>>
19 >>> I've been playing around with Gentoo/FreeBSD and have been noticing that emerge
20 >>> is leaving orphaned processes behind on that platform. Seems to be
21 >>> ecompressdir getting hung up. emerge itself just moves on, but after I
22 >>> accumulated ~5 of those stuck ecompressdir processes in a single run, I kill
23 >>> -9'ed them all. Didn't see side-effects similar to what's described in the
24 >>> original post, but the way to detect this issue might be to look for orphaned
25 >>> children processes lacking a parent PID, then reap them.
26 >>
27 >>
28 >> Updating my FreeBSD VM again, I captured one of the error messages that's
29 >> leading to these orphaned ecompressdir processes:
30 >>
31 >> /usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: cannot make pipe for
32 >> process substitution: File exists
33 >> /usr/lib/portage/python3.5/ebuild-helpers/ecompressdir: line 72:
34 >> /ramfs/portage/sys-freebsd/boot0-10.3/temp/sh-np-1865519000: ambiguous redirect
35 >> ecompressdir: bzip2 -9 /usr/share/man
36 >> * The ebuild phase 'install' with pid 32075 appears to have left an orphan
37 >> * process running in the background.
38 >>
39 >>
40 >> And a second one:
41 >> /ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
42 >> cannot make pipe for process substitution: File exists
43 >> /ramfs/portage/._portage_reinstall_.pesqhjhn/bin/ebuild-helpers/ecompressdir:
44 >> line 72: /ramfs/portage/sys-apps/grep-2.25/temp/sh-np-474708936: ambiguous redirect
45 >> ecompressdir: bzip2 -9 /usr/share/man
46 >> ecompressdir: bzip2 -9 /usr/share/info
47 >> ecompressdir: bzip2 -9 /usr/share/doc
48 >> * The ebuild phase 'install' with pid 60185 appears to have left an orphan
49 >> * process running in the background.
50 >>
51 >> Not sure the exact cause. Any additional info I can provide?
52 >>
53 >> --J
54 >
55 > Looks like a problem with bash. Make sure your bash has the fix for this
56 > issue:
57 >
58 > https://bugs.gentoo.org/show_bug.cgi?id=447810
59 >
60 > What version of bash is it? Maybe try some other versions.
61
62 Latest version in ~arch, bash-4.3_p42-r2.
63
64 Doesn't appear to be completely tied to FreeBSD, either, as there's this
65 unanswered topic on the forums from Nov 2015:
66 https://forums-lb.gentoo.org/viewtopic-t-1032574.html?sid=5d7566d09a49ba06124032598d3ad362
67
68 Just looks like FreeBSD trips it up far more often, as I've only seen it there.
69
70 --J

Replies

Subject Author
Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles Joshua Kinard <kumba@g.o>