Due to the asynchronous nature of signal delivery, it's possible to check on the execReadlines child process at a point where output has been closed but the process is still, technically, alive. This situation appeared in particular when running the nosetests on a system with one CPU. To make the behavior of reading a line from an exiting process deterministic, wait for the process to finish when output is complete. The consequence of this is that processes that runs forever will cause execReadlines to block forever, and the answer is to not run such a process with execReadlines.
This commit also combines the fix for the bad use of WIFSIGNALED in 2275dfc76f4417cbe1b620d19b6558ec007d3bdc and the change in 807aa60ccb3cc0bc74581b58f04d0777d7b35985 to make the exit behavior make more sense. The tests were already looking for the exceptions raised by the latter commit, and sometimes they found them.
(cherry picked from commit 807aa60ccb3cc0bc74581b58f04d0777d7b35985)
Related: rhbz#1188287