phd: collect core when killing non-booting guest#1079
Conversation
this may or may not prove useful in practice; if we're lucky something got funky in device emulation and we can see a stuck thread. on the other hand, if we're unlucky the guest is stuck in a loop and all we see is one vCPU was running while everything else was idle.
| ); | ||
| let proc = self.server.as_ref().unwrap(); | ||
| proc.core(); | ||
| anyhow::bail!("timed out while waiting to boot") |
There was a problem hiding this comment.
maybe we ought to stuff the core's path in this error so that it gets printed in the test failure as well as in its logs?
There was a problem hiding this comment.
i think i've got it so that the warn!("core written to {}", core_path); would be right above this in the rendered buildomat output, so it should be pretty easy to notice if you've gotta look at the logs.. it stubbornly does not want to do the thing though so i guess we'll see?
anyway i'm mostly thinking that until very recently most timed out while waiting to boot really meant that i did something funky with the guest test image or adapter. there the core wouldn't have been nearly as useful as looking at the guest's serial history, so i don't wanna nudge in a misleading direction.
|
|
2 participants
this may or may not prove useful in practice; if we're lucky something got funky in device emulation and we can see a stuck thread. on the other hand, if we're unlucky the guest is stuck in a loop and all we see is one vCPU was running while everything else was idle. in this case, at least, hopefully the serial console says something about the condition (it usually does, from experience)
this does the immediate thing in #1034. theoretically I've put the core in the right spot to get slurped up when we tar up the rest of the phd run artifacts so I'll rerun the phd job 'til we get a core...?