Skip to content
  • John Snow's avatar
    1611e6cf
    python/machine: handle "fast" QEMU terminations · 1611e6cf
    John Snow authored
    
    
    In the case that the QEMU process actually launches -- but then dies so
    quickly that we can't establish a QMP connection to it -- QEMUMachine
    currently calls _post_shutdown() assuming that it never launched the VM
    process.
    
    This isn't true, though: it "merely" may have failed to establish a QMP
    connection and the process is in the middle of its own exit path.
    
    If we don't wait for the subprocess, the caller may get a bogus `None`
    return for .exitcode(). This behavior was observed from
    device-crash-test; after the switch to Async QMP, the timings were
    changed such that it was now seemingly possible to witness the failure
    of "vm.launch()" *prior* to the exitcode becoming available.
    
    The semantic of the `_launched` property is changed in this
    patch. Instead of representing the condition "launch() executed
    successfully", it will now represent "has forked a child process
    successfully". This way, wait() when called in the exit path won't
    become a no-op.
    
    Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
    Reviewed-by: default avatarWillian Rampazzo <willianr@redhat.com>
    Message-id: 20211118204620.1897674-6-jsnow@redhat.com
    Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
    1611e6cf
    python/machine: handle "fast" QEMU terminations
    John Snow authored
    
    
    In the case that the QEMU process actually launches -- but then dies so
    quickly that we can't establish a QMP connection to it -- QEMUMachine
    currently calls _post_shutdown() assuming that it never launched the VM
    process.
    
    This isn't true, though: it "merely" may have failed to establish a QMP
    connection and the process is in the middle of its own exit path.
    
    If we don't wait for the subprocess, the caller may get a bogus `None`
    return for .exitcode(). This behavior was observed from
    device-crash-test; after the switch to Async QMP, the timings were
    changed such that it was now seemingly possible to witness the failure
    of "vm.launch()" *prior* to the exitcode becoming available.
    
    The semantic of the `_launched` property is changed in this
    patch. Instead of representing the condition "launch() executed
    successfully", it will now represent "has forked a child process
    successfully". This way, wait() when called in the exit path won't
    become a no-op.
    
    Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
    Reviewed-by: default avatarWillian Rampazzo <willianr@redhat.com>
    Message-id: 20211118204620.1897674-6-jsnow@redhat.com
    Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
Loading