Repository navigation
feat: tell the user when the Podman Machine runs out of memory and offer more - #2249
Merged
Merged
Conversation
…fer more When the macOS VM runs out of memory its kernel kills whatever uses the most, usually MySQL or a PHP worker, and commands that need them hang or fail with nothing pointing at the cause. lerd now reads the VM's serial console log on the host and counts those kills since the last boot, so the check costs nothing inside the VM. The dashboard shows a banner while the VM has had kills, naming what was killed, with a button that restarts the VM with 2 GB more, never past half the Mac's memory, and then runs the normal start so every container comes back. `lerd machine memory` reports the same and takes a size in GB to do the restart from the terminal, and `lerd doctor` flags it under Containers & Images. A size set this way is kept, since lerd start only ever raises the VM to its default.
 [Medium impact] The latest changes appear safe to merge, with one non-blocking warning-display issue remaining from the previous review. Findings
Fix with agent prompt### Issue 1
internal/ui/web/src/components/MachineMemoryBanner.svelte:undefined-42
`dismissedAt` lasts for the page's lifetime, but the kill count resets each boot. If the user dismisses three kills, restarts the VM, and then gets one new kill, `1 > 3` stays false. The dashboard hides the new warning until the count exceeds the old one. Reset dismissal when the boot changes instead of comparing counts across boots.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.SummaryThe PR adds memory warnings and a guided VM resize from the dashboard and CLI.
Reviews (5) · Last reviewed commit: "fix: say when the VM memory check could ..." · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| } | ||
| </script> | ||
|
|
||
| {#if kills.length > dismissedAt || resizing} |
There was a problem hiding this comment.
dismissedAt lasts for the page's lifetime, but the kill count resets each boot. If the user dismisses three kills, restarts the VM, and then gets one new kill, 1 > 3 stays false. The dashboard hides the new warning until the count exceeds the old one. Reset dismissal when the boot changes instead of comparing counts across boots.
Prompt To Fix With AI
This is a comment left during a code review.
Path: internal/ui/web/src/components/MachineMemoryBanner.svelte
Line: 42
Comment:
**New memory warnings stay hidden**
`dismissedAt` lasts for the page's lifetime, but the kill count resets each boot. If the user dismisses three kills, restarts the VM, and then gets one new kill, `1 > 3` stays false. The dashboard hides the new warning until the count exceeds the old one. Reset dismissal when the boot changes instead of comparing counts across boots.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Member
Author
There was a problem hiding this comment.
Fixed in 27b55f4, a count lower than the dismissed one means a new boot and resets the dismissal.
A remote session without full access could post to the resize endpoint and stop every container, so the restart now needs the same host-action authority as the other host operations, while the finding itself stays readable. When setting the memory fails after the VM is already stopped, lerd still runs the start so the sites come back on the old size, and reports both errors. The banner now shows why a restart failed, keeps the button away while another start or stop is running, brings itself back after a reboot even when the new count is lower than the one dismissed, and no longer tells the user the Mac is out of memory when the VM's size simply could not be read.
…e lookup A missing console log or a failed machine list used to come back as an empty record, so lerd doctor and lerd machine memory told the user the VM had not run out of memory when neither could check. The check now returns an error, doctor shows it as a warning, the command fails with it, and the dashboard endpoint answers 500 so the banner keeps what it had. The machine lookup also goes through the bounded machine query now, so a VM wedged after sleep cannot leave a hung podman machine list behind every minute's poll.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the Podman Machine VM on macOS runs out of memory, its kernel kills whatever is using the most, usually MySQL or a PHP worker. Commands that need them then hang or fail, and nothing in lerd points at the cause. Switching a site with Horizon and scheduler workers to the container runtime was enough to do it on a 4 GB VM: fourteen PHP processes at about 140 MB each next to MySQL, and the kernel killed mysqld six times and the VM's own systemd twice within twenty minutes.
lerd now reads the VM's serial console log, which podman keeps on the host, and counts the out-of-memory kills since the VM last booted. Reading it costs nothing inside the VM, so the dashboard checks it once a minute.
While there have been kills, the dashboard shows a banner saying how many and what was killed, with a button that restarts the VM with 2 GB more, never past half of the Mac's memory, after a confirmation. The restart stops the VM, sets its memory and runs the normal start, so every container comes back with its port forwards, and its progress shows in the banner. When the Mac has nothing more to give, the banner says so and suggests stopping unused sites or workers instead. Dismissing it hides it until the next kill.
The same finding is available from the terminal as
lerd machine memory, which takes a size in GB to do the restart, andlerd doctorreports it under Containers & Images. A size set this way is kept, sincelerd startonly ever raises the VM to its default and never lowers it. Linux has no VM, so none of this shows there.