[Heartbeat] The /tmp folder doesn’t seem to be getting cleaned up
#35646
Assignees
Labels
Comments
paulb-elastic
added
bug
Team:obs-ds-hosted-services
|
Pinging @elastic/uptime (Team:Uptime) |
|
Quick update, Private Location still running and can see Which corresponds with the |
|
Hmmmm, I've just confirmed that file based reload does correctly reload the monitor with delete, I'll keep investigating. Perhaps it is only on agent that this fails (that's much harder to debug) |
|
@andrewvc heartbeat is not cleaning the unzipped folder for project monitors after every run. Considering it fetches the source for every run, it adds up. It doesn't seem to be an agent issue |
Merged
andrewvc
added a commit
that referenced
this issue
Jun 22, 2023
Fixes #35646 by only unpacking project monitors once. This fixes the ever growing temp folder issue and is more efficient to boot. Previously we would call fetch on a monitor source every time it was run, but only cleanup the fetched resource once, when the monitor was unloaded. We now fetch once and cleanup once. This project also fixes the very confusing issue of two files browser/project.go and browser/source/project.go, we have renamed browser/project.go to browser/sourcejob.go which makes reasoning about this change simpler.
mergify bot
pushed a commit
that referenced
this issue
Jun 22, 2023
Fixes #35646 by only unpacking project monitors once. This fixes the ever growing temp folder issue and is more efficient to boot. Previously we would call fetch on a monitor source every time it was run, but only cleanup the fetched resource once, when the monitor was unloaded. We now fetch once and cleanup once. This project also fixes the very confusing issue of two files browser/project.go and browser/source/project.go, we have renamed browser/project.go to browser/sourcejob.go which makes reasoning about this change simpler. (cherry picked from commit f7111dc)
andrewvc
added a commit
that referenced
this issue
Jun 22, 2023
Fixes #35646 by only unpacking project monitors once. This fixes the ever growing temp folder issue and is more efficient to boot. Previously we would call fetch on a monitor source every time it was run, but only cleanup the fetched resource once, when the monitor was unloaded. We now fetch once and cleanup once. This project also fixes the very confusing issue of two files browser/project.go and browser/source/project.go, we have renamed browser/project.go to browser/sourcejob.go which makes reasoning about this change simpler. (cherry picked from commit f7111dc) Co-authored-by: Andrew Cholakian <[email protected]>
|
Moving to Done Done as it's been validate by @paulb-elastic and myself. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are observing that the
/tmpfolder within the running container of an Elastic Agent being used for a Private Location, is continually growing and may eventually cause the host to fill up.This has been observed with both 8.7.0 and 8.8.0, where
/tmpis growing ~40MB per day (on an example Private Location running 5 browser monitors, 3 of which run every 5 minutes, 2 of which run every 3 minutes).Looking at
/tmpon the running container, there are manyelastic-synthetics-unzip-nnnnsubfolders, for example:The text was updated successfully, but these errors were encountered: