so we're using the lame "gzip ~/.cache/pants" appr...
# general
so we're using the lame "gzip ~/.cache/pants" approach in our CICD But have started getting
tar ./lmdb_store/files/e/data.mdb file change as we read it
errors. What might be triggering this? My suspicion is pantsd is flushing changes while tar is running. Is there a way to force pantsd to cleanly flush and exit?
Hmm, not familiar with that error. By 'lame “gzip ~/.cache/pants” approach' do you mean that you save that dir to (e.g.,) S3 at the end of a run and restore it at the beginning of a subsequent run? If so, what cache key do you use for this?
(not directly related to your issue, just curious)
There is no clean shutdown for pantsd today
@rapid-bird-79300 You're doing something similar I believe? Have you ever hit this issue?
the not-lame way: reapi server the lame way: at the end of the build,
tar -czf
up the ~/.cache/pants directory, upload it to s3. at the start of the build, pull it from s3 and untar it
Got it
I would be remiss in not plugging Toolchain's remote caching (and soon remote execution), but that is not a replacement for figuring this out.
Your flushing hypothesis seems reasonable, I think @witty-crayon-22786 would know more
I would love to use toolchain. Just not an option at the moment :(
I stumbled across earlier today which talks about how to kill the daemon:
To kill the daemon, you can run either
or `kill-pantsd`:
```./pants clean-all
./pants kill-pantsd```
@gifted-agency-25998 are you seeing the new red banner on those docs? That advice does not work for Pants v2.
You should consider Pants v1 and Pants v2 totally separate tools. Almost no Pants v1 advice from those pages will be applicable to Pants v2.
Yes we've had very similar issues in the past. We now use a separate pipeline which generates the cache from a clean state (no pulling the cache at the start) and then uploads it to S3. Then CI builds that run pants can pull the cache as needed. We have not seen that issue since.
Interesting! And also annoying to have to do.
If someone wants to add a clean shutdown command, that would end up being useful!
Also, silly and non-rigorous hack, but does adding a short sleep to wait out the flush help in practice?
I was thinking a capped loop on the tarring.
my bad! For some reason, I was linked to the daemon anchor which meant that I didn't see red banner was above the fold
Just wondering if there is now a better solution than the capped loop when tarring? Apart from remote caching of course @happy-kitchen-89482 @enough-analyst-54434
Nothing has changed about pantsd shutdown since this thread began, no.
👍 1