regular termination of microcom should not lead to a backtrace about labgrid HOT 5 CLOSED

It turned out I end microcom with Ctrl-\ Ctrl-c. In this case the Ctrl-c is no longer delivered to microcom (which would then restore the terminal settings), but to Python, which then prints the backtrace. microcom is then ended without the signal handler being executed and the terminal may be garbled.
I'll have to reprogram my fingers to end microcom with Ctrl-\ Ctrl-\ and this problem does not show up

from labgrid.

Would this work better if labgrid would send SIGTERM to the microcom process?

from labgrid.

Look at /usr/lib/python3.5/subprocess.py:249:

def call(*popenargs, timeout=None, **kwargs):
"""Run command with arguments. Wait for command to complete or
timeout, then return the returncode attribute.

The arguments are the same as for the Popen constructor.  Example:

retcode = call(["ls", "-l"])
"""
with Popen(*popenargs, **kwargs) as p:
    try:
        return p.wait(timeout=timeout)
    except:
        p.kill()
        p.wait()
        raise

Here is the problem: Both python and microcom receive the Ctrl-C. If python comes to first handle the Ctrl-C then microcom will be killed and thus cannot cleanup the terminal

from labgrid.

@saschahauer is this a still a problem that needs a workaround? Otherwise I'll close this issue.

from labgrid.

Clsoing this as no longer requiring action

from labgrid.