Skip to content

Conversation

@roypat
Copy link
Contributor

@roypat roypat commented May 29, 2025

Changes

In Microvm.kill() we have a sanity check for ensuring the firecracker
process wrote the correct pid to its pidfile: We ps | grep for the
jailer id of the supposedly dead firecracker process and see if any
process that has "fircracker" somewhere in its argv is using it (with
the somewhat reasonable assumption that this would be exactly the
firecracker process we just tried to kill). Howver, if the firecracker
process isnt daemonized, then we spawn it under screen, and now we
have two processes that contain both the jailer id and the name
"firecracker" in its argv, because screen fork()s into firecracker in
this case. Now if we kill firecracker, screen might stick around a bit
longer (because we only explicitly wait for firecracker to terminate),
and the sanity check might incorrectly pick up the screen process as a
firecracker process and cause a spurious test failure.

Fix this by having the check explicitly ignore all screen processes.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

  • I have read and understand CONTRIBUTING.md.
  • I have run tools/devtool checkstyle to verify that the PR passes the
    automated style checks.
  • I have described what is done in these changes, why they are needed, and
    how they are solving the problem in a clear and encompassing way.
  • I have updated any relevant documentation (both in code and in the docs)
    in the PR.
  • I have mentioned all user-facing changes in CHANGELOG.md.
  • If a specific issue led to this PR, this PR closes the issue.
  • When making API changes, I have followed the
    Runbook for Firecracker API changes.
  • I have tested all new and changed functionalities in unit tests and/or
    integration tests.
  • I have linked an issue to every new TODO.

  • This functionality cannot be added in rust-vmm.

roypat added 3 commits May 29, 2025 12:53
"No more than 12 if statements in a function" does not a good lint make.

Signed-off-by: Patrick Roy <[email protected]>
Clean up the error messages we print when running into the "firecracker
pid was killed, but process with its jailer id still exists" case: Also
print the PID of the offending process, as well as filter out
non-firecracker processes from the error message (otherwise the
error message always contained the grep process itself, which was
confusing).

Note that `cmd` must be the last column, as otherwise ps will truncate
it.

Signed-off-by: Patrick Roy <[email protected]>
In Microvm.kill() we have a sanity check for ensuring the firecracker
process wrote the correct pid to its pidfile: We ps | grep for the
jailer id of the supposedly dead firecracker process and see if any
process that has "fircracker" somewhere in its argv is using it (with
the somewhat reasonable assumption that this would be exactly the
firecracker process we just tried to kill). Howver, if the firecracker
process isnt daemonized, then we spawn it under `screen`, and now we
have two processes that contain both the jailer id and the name
"firecracker" in its argv, because screen fork()s into firecracker in
this case. Now if we kill firecracker, screen might stick around a bit
longer (because we only explicitly wait for firecracker to terminate),
and the sanity check might incorrectly pick up the screen process as a
firecracker process and cause a spurious test failure.

Fix this by having the check explicitly ignore all screen processes.

Signed-off-by: Patrick Roy <[email protected]>
@roypat roypat added the Status: Awaiting review Indicates that a pull request is ready to be reviewed label May 29, 2025
@codecov
Copy link

codecov bot commented May 29, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.94%. Comparing base (10dfa03) to head (d888d5a).
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5232      +/-   ##
==========================================
+ Coverage   82.89%   82.94%   +0.05%     
==========================================
  Files         250      250              
  Lines       26965    26965              
==========================================
+ Hits        22353    22367      +14     
+ Misses       4612     4598      -14     
Flag Coverage Δ
5.10-c5n.metal 83.39% <ø> (ø)
5.10-m5n.metal 83.39% <ø> (+<0.01%) ⬆️
5.10-m6a.metal 82.60% <ø> (-0.01%) ⬇️
5.10-m6g.metal 79.22% <ø> (ø)
5.10-m6i.metal 83.37% <ø> (-0.01%) ⬇️
5.10-m7a.metal-48xl 82.59% <ø> (?)
5.10-m7g.metal 79.22% <ø> (ø)
5.10-m7i.metal-24xl 83.34% <ø> (?)
5.10-m7i.metal-48xl 83.34% <ø> (?)
5.10-m8g.metal-24xl 79.22% <ø> (?)
5.10-m8g.metal-48xl 79.21% <ø> (?)
6.1-c5n.metal 83.43% <ø> (+<0.01%) ⬆️
6.1-m5n.metal 83.43% <ø> (+<0.01%) ⬆️
6.1-m6a.metal 82.65% <ø> (ø)
6.1-m6g.metal 79.22% <ø> (ø)
6.1-m6i.metal 83.42% <ø> (-0.01%) ⬇️
6.1-m7a.metal-48xl 82.63% <ø> (?)
6.1-m7g.metal 79.21% <ø> (-0.01%) ⬇️
6.1-m7i.metal-24xl 83.44% <ø> (?)
6.1-m7i.metal-48xl 83.44% <ø> (?)
6.1-m8g.metal-24xl 79.22% <ø> (?)
6.1-m8g.metal-48xl 79.21% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Split an assertion on a conjunction into multiple assertions, to make it
easier to see which of the individual checks failed.

Suggested-by: Babis Chalios <[email protected]>
Signed-off-by: Patrick Roy <[email protected]>
@roypat roypat enabled auto-merge (rebase) May 29, 2025 13:47
@roypat roypat merged commit 0324791 into firecracker-microvm:main May 29, 2025
6 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Status: Awaiting review Indicates that a pull request is ready to be reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants