When the Scheduler._terminate_tasks method clears self._task_queues, it prevents exit listeners from being called for an EbuildExecuter instance that has previously called self.scheduler.scheduleSetup(setup_phase). This causes the parent MergeListItem to remain in Scheduler._running_tasks indefinitely, and the event loop just hangs forever in the self._thread_condition.wait(wait_timeout) call. The backtrace of this state is as follows: (Pdb) bt /usr/lib/python-exec/python3.4/emerge(50)<module>() -> retval = emerge_main() /usr/lib64/python3.4/site-packages/_emerge/main.py(1229)emerge_main() -> return run_action(emerge_config) /usr/lib64/python3.4/site-packages/_emerge/actions.py(3266)run_action() -> retval = action_build(emerge_config, spinner=spinner) /usr/lib64/python3.4/site-packages/_emerge/actions.py(525)action_build() -> retval = mergetask.merge() /usr/lib64/python3.4/site-packages/_emerge/Scheduler.py(1042)merge() -> rval = self._merge() /usr/lib64/python3.4/site-packages/_emerge/Scheduler.py(1444)_merge() -> self._main_loop() > /usr/lib64/python3.4/site-packages/_emerge/Scheduler.py(1421)_main_loop() -> self._event_loop.iteration() /usr/lib64/python3.4/site-packages/portage/util/_eventloop/EventLoop.py(222)iteration() -> self._thread_condition.wait(wait_timeout) The Scheduler._running_tasks state looks like this: (Pdb) p next(iter(self._running_tasks.values())) <_emerge.MergeListItem.MergeListItem object at 0x7f67b275f900> (Pdb) p next(iter(self._running_tasks.values()))._current_task <_emerge.EbuildBuild.EbuildBuild object at 0x7f67b275f9f8> (Pdb) p next(iter(self._running_tasks.values()))._current_task._current_task <_emerge.EbuildExecuter.EbuildExecuter object at 0x7f67acf129d8> (Pdb) p next(iter(self._running_tasks.values()))._current_task._current_task._exit_listeners [<bound method EbuildBuild._build_exit of <_emerge.EbuildBuild.EbuildBuild object at 0x7f67b275f9f8>>] (Pdb) p next(iter(self._running_tasks.values()))._current_task._current_task.returncode 1
(In reply to Zac Medico from comment #0) > (Pdb) p > next(iter(self._running_tasks.values()))._current_task._current_task. > _exit_listeners > [<bound method EbuildBuild._build_exit of <_emerge.EbuildBuild.EbuildBuild > object at 0x7f67b275f9f8>>] > (Pdb) p > next(iter(self._running_tasks.values()))._current_task._current_task. > returncode > 1 The 1 returncode suggests that there may have been an _async_wait callback registered when it went into the endless sleep.
I've posted a patch to fix Eventloop handling of idle_add/call_soon callbacks: https://archives.gentoo.org/gentoo-portage-dev/message/ba1ec7812ec5a839896cc1a880b7f3f4 https://github.com/gentoo/portage/pull/160 That seems to be the only problem, since the code from bug 425554 should handle the interaction between Scheduler._terminate_tasks and _schedule_setup, as long as task.cancel() works appropriately (the EventLoop patch should fix that).
This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=dac5089eb7908e9fd643f46c913515082077281e
Fixed in 2.3.6.