| Summary: | sys-apps/portage-2.2.01.21688+ dies during emerge due to Errno 35 | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Fabian Groffen <grobian> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | dev-portage, srcshelton, VED03370 |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | OS X | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=264435 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 462382 | ||
|
Description
Fabian Groffen
2013-02-09 12:53:41 UTC
You should check to see if the O_NONBLOCK flag is enabled by default for stdout (it shouldn't be):
#!/usr/bin/env python
import fcntl
import os
import sys
stdout_flags = fcntl.fcntl(sys.stdout.fileno(), fcntl.F_GETFL)
if stdout_flags & os.O_NONBLOCK:
sys.stdout.write("O_NONBLOCK\n")
I have the same problem on OS X 10.8, and running the code from Comment 1 outputs nothing. However, using 'emerge --quiet-build' does seem to fix the issue. (In reply to comment #2) > I have the same problem on OS X 10.8, and running the code from Comment 1 > outputs nothing. > > However, using 'emerge --quiet-build' does seem to fix the issue. agreed, IMO it's some buffer that overflows (isn't read as immediate as necessary) Burcin Erocal <burcin@erocal.org> wrote: It seems that the problem was introduced between these two merges. cefe9ddc5e1b8a1ba727afddd11638723875949c 2013-01-05 19:12 754956bff8273df8ce2c3d9f6ff7fb22126ebd41 2013-01-10 22:01 suspect: e132ec4f753b9df4769f7e58dfc661617c7375b8 (PipeLogger) (need to test) (In reply to comment #5) > suspect: > > e132ec4f753b9df4769f7e58dfc661617c7375b8 (PipeLogger) > > (need to test) I don't think that commit changes any behavior. Maybe this one, though: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d916da77dfc94eb30c6f512f9d7d727a8f28600c checked both, not the problem. 2.2.01.21476 works 2.2.01.21535 works 2.2.01.21567 broken 2.2.01.21580 broken broken 21565:80a02c9243bf Use EventLoop, no SchedulerInterface if possible broken 21563:01e5fda3f1e1 SpawnProcess: handle fcntl ENOTTY for FreeBSD broken 21548:762ffde02f9f SpawnProcess: stdout_fd FD_CLOEXEC works 21547:af05371e830f ManifestTask: use PipeLogger for monitoring victim: 762ffde02f9f -> git: 2a05612d23561d4606e93e73a8e021dc91291ff6 backing out 762ffde02f9f on the latest (21580) results in working portage I don't quite understand why we need FD_CLOEXEC here, but I disabled it for Darwin in 80f9a5dff0605a5114bbed93464be68ffc0e668a. (In reply to comment #9) > I don't quite understand why we need FD_CLOEXEC here, but I disabled it for > Darwin in 80f9a5dff0605a5114bbed93464be68ffc0e668a. It's just good practice for any file descriptor that doesn't explicitly need to be inherited through an exec call. It's good to skip it on platforms where it causes problems, so I've merged your fix. Fix released in 2.2.01.21858 *** Bug 462706 has been marked as a duplicate of this bug. *** It turns out that the wrong fcntl commands were used (F_GETFD/F_SETFD should have been used instead of F_GETFL/F_SETFL): http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=30c652a9db1014fc720f7d6055520a07b731c984 If someone would like to test setting _disable_cloexec_stdout = False at the top of ${EPREFIX}/usr/lib/portage/pym/_emerge/SpawnProcess.py on Darwin, then that would be great. This commit is in Prefix tree now (2.2.4.*) it solves the disconnect problem on Solaris, which I'm very happy with! Darwin bit needs testing. It appears as this has fixed the problem on Darwin. I'll keep it in testing for a bit longer. I did quite some emerging with _disable_cloexec_stdout = False on Darwin, and didn't find any problem, so I feel it's good to go. Zac, would you please remove this in master at your earliest convenience? |