action #1305
closedBetter management of crashed runs
Description
We need a way to identify the sessions where QEMU or one of the components of os-autoinst die (core dump)
Updated by mlin7442 about 10 years ago
hmm...I haven't participated sprint meeting, so I have several questions.
1) the message from STDERR doesn't good enough in this case? e.g. http://opensuseqa.suse.de/tests/901/file/autoinst-log.txt
2) how to reproduce a crashed QEMU within openQA manually?
Updated by coolo about 10 years ago
1) checking the autoinst-log manually is ok, but not good enough. as user I would actually expect a reschedule as work around or at least a big fat "retrigger me" :)
2) killall -SEGV qemu-kvm
Updated by mlin7442 about 10 years ago
1) ok, got it :-)
2) yep, of course killall -SEGV let QEMU quit, my bad description of question 2...actually I want to know how to generate a core dumped QEMU ie. a crash inside of QEMU, probably a segmentation fault or something else, but afterwards I think it's not important for this topic, so forget about it.
Updated by coolo about 10 years ago
actually a SEGV signal will trigger a core dump
Updated by mlin7442 about 10 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 60
https://github.com/openSUSE-Team/openQA/pull/60 and https://github.com/os-autoinst/os-autoinst/pull/21, may seems ugly, but it can get rid of fatal error from qemu backend, ie. cancel/reschedule the job
Updated by mlin7442 about 10 years ago
- Status changed from In Progress to Resolved
- % Done changed from 60 to 100
now, it shall can handle when qemu backend crashed, I think it's just enough for us, the other reason caused a crashed that need check the autoinst-log, may there have a bug inside of os-autoinst or tests scripts what useless just rescheduled job. hence I'd just close this task and if anyone think it's not good enough for us or have any idea where we can improvement then just reopen this again. :-)