Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flintlock should know when a mVM dies #178

Closed
Callisto13 opened this issue Oct 28, 2021 · 1 comment · Fixed by #255
Closed

Flintlock should know when a mVM dies #178

Callisto13 opened this issue Oct 28, 2021 · 1 comment · Fixed by #255
Labels
kind/bug Something isn't working priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

Comments

@Callisto13
Copy link
Member

Callisto13 commented Oct 28, 2021

What happened:
An unrelated config issue caused the firecracker process to die shortly after boot. It appeared that flintlock did not notice this (at least according to the logs).

What did you expect to happen:
Flintlock should notice that an mVM had died, and it should at least log that this has happened.

How to reproduce it:
Going off this commit (nothing special about it, just head of main rn and happens to contain an issue. you could also repro with a new commit and manually kill the pid probably) create a mVM with the config in hack/scripts/payload/CreateMicroVM.json.

You should see the firecracker process start, then after a few moments die. The firecracker logs will talk about no init found, but that is not important here. The issue is that flintlock did not appear to notice.

Anything else you would like to add:
We do not have Get merged right now, so curious to know what the status knows.

Environment:

  • flintlock version:
  • OS (e.g. from /etc/os-release):
@Callisto13 Callisto13 added the kind/bug Something isn't working label Oct 28, 2021
@Callisto13 Callisto13 changed the title Flintlock should know when a mVM stops Flintlock should know when a mVM dies Oct 28, 2021
@richardcase
Copy link
Member

We also need to think about a unresponsive vm.

@richardcase richardcase added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Nov 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants