On 06/06/2013 10:37 AM, Markus Trippelsdorf wrote:
On 2013.06.06 at 10:18 -0400, Peter Hurley wrote:
On 06/06/2013 07:54 AM, Markus Trippelsdorf wrote:
Since v3.8.0 several people reported intermittent IO errors that happen
during high system load while using "emerge" under Gentoo:
...
File "/usr/lib64/portage/pym/portage/util/_eventloop/EventLoop.py", line
260, in iteration
if not x.callback(f, event, *x.args):
File "/usr/lib64/portage/pym/portage/util/_async/PipeLogger.py", line 99,
in _output_handler
stdout_buf[os.write(stdout_fd, stdout_buf):]
File "/usr/lib64/portage/pym/portage/__init__.py", line 246, in __call__
rval = self._func(*wrapped_args, **wrapped_kwargs)
OSError: [Errno 5] Input/output error
Looks to me like a user-space bug: EIO is returned when the other
end of the "pipe" has been closed.
FWIW, I didn't see where the OP tried to revert
'SpawnProcess: stdout_fd FD_CLOEXEC'
The only non-emerge related comment (#21 in the link provided) refers to
'a similar issue sometimes happened when I built Firefox by hand [..snip..]
And it would randomly crash during the build.
Since I've recompiled Python with gcc-4.6 this issue also never occurred
again.'
That comment doesn't really corroborate the reported bug.
That comment was from me (I use 'octoploid' for blog trolling, etc.) and
is wrong. The Firefox build issue happend again today. See also the rest
of my mail:
(A similar issue also happens when building Firefox since v3.8.0. But
because Firefox's build process doesn't raise an exception it just
dies at random points without giving a clue.)
Please note that both the Firefox build process and Portage (emerge)
are implemented in Python.
Based on the other reports from Mikael and David, I suspect this problem
may have to do with my commit 699390354da6c258b65bf8fa79cfd5feaede50b6:
pty: Ignore slave pty close() if never successfully opened
This commit poisons the pty under certain error conditions that may
occur from parallel open()s (or parallel close() with pending write()).
It's unclear to me which error condition is triggered and how user-space
got an open file descriptor but that seems the most likely. Is the problem
reproducible enough that a debug patch would likely trigger?
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
