Actions
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)
Actions
Added by aplanas over 10 years ago. Updated about 10 years ago.
Description
We need a way to identify the sessions where QEMU or one of the components of os-autoinst die (core dump)
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?
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
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.
actually a SEGV signal will trigger a core dump
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
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. :-)