With latest portage (python?) I do run regularly in a situation like this: >>> Jobs: 26 of 30 complete Load avg: 12.0, 12.3, 12.7 >>> Jobs: 26 of 30 complete, 1 running Load avg: 12.0, 12.3, 12.7 >>> Emerging (27 of 30) media-sound/pulseaudio-12.0::gentoo >>> Jobs: 26 of 30 complete, 1 running Load avg: 12.0, 12.3, 12.7 Exception in callback AsynchronousTask.wait() handle: <Handle AsynchronousTask.wait()> Traceback (most recent call last): File "/usr/lib64/python3.5/asyncio/events.py", line 127, in _run self._callback(*self._args) File "/usr/lib64/python3.5/site-packages/_emerge/AsynchronousTask.py", line 84, in wait self._wait_hook() File "/usr/lib64/python3.5/site-packages/_emerge/AsynchronousTask.py", line 195, in _wait_hook self._exit_listener_stack.pop()(self) File "/usr/lib64/python3.5/site-packages/_emerge/EbuildBuild.py", line 68, in _start_with_metadata settings.configdict["pkg"]["SRC_URI"], = aux_get_task.future.result() File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result raise self._exception portage.exception.PortageKeyError: 'media-sound/pulseaudio-12.0' The emerge process does not stop (not even after hours).
Allowing the process to continue running like this can be useful for debugging, since we can get a pdb debugger shell by sending it a SIGUSR1 signal. Maybe allowing the process to hang encourages more bug reports, which is necessary for those bugs to get fixed. (In reply to Toralf Förster from comment #0) > File "/usr/lib64/python3.5/site-packages/_emerge/EbuildBuild.py", line > 68, in _start_with_metadata > settings.configdict["pkg"]["SRC_URI"], = aux_get_task.future.result() > File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result > raise self._exception > portage.exception.PortageKeyError: 'media-sound/pulseaudio-12.0' For this particular error we really need to do something about bug 639374, I suppose we could solve this by caching the ebuilds somewhere, or by using some form of copy-on-write storage to cache a readonly snapshot of the entire ebuild repository.
Maybe a good compromise would be to automatically drop to a debug shell if we have a tty for stdin/stdout/stderr, and if we don't have a tty then simply kill the process.
Created attachment 536760 [details, diff] exit after unhandled exception
(In reply to Zac Medico from comment #2) I like this idea. +1
(In reply to Toralf Förster from comment #4) > (In reply to Zac Medico from comment #2) > I like this idea. > +1 Great! Posted for wider review: https://github.com/gentoo/portage/pull/327 https://archives.gentoo.org/gentoo-portage-dev/message/19c562c14047bf92d3c9f4a3b7a17273
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=6b50ba69f5a8e311fcddfb2e5c203631bd292c71 commit 6b50ba69f5a8e311fcddfb2e5c203631bd292c71 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-06-21 21:03:38 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-06-27 03:04:38 +0000 AsyncioEventLoop: exit after unhandled exception (bug 658684) Fix portage commands to exit immediately for any unhandled exceptions that are raised while the asyncio event loop is running without a tty. If we have a tty then start the debugger, since in might aid in diagnosis of the problem. In order to avoid potential interference with API consumers, do not call set_exception_handler unless portage._internal_caller is True. Bug: https://bugs.gentoo.org/658684 pym/portage/util/_eventloop/asyncio_event_loop.py | 31 +++++++++++++++++++++++ 1 file changed, 31 insertions(+)
(In reply to Larry the Git Cow from comment #6) this patch works here at the tinderbox - thx
