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?

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 love to use toolchain. Just not an option at the moment :(

I stumbled across https://v1.pantsbuild.org/invoking.html#the-pants-daemon-pantsd earlier today which talks about how to kill the daemon:

To kill the daemon, you can run either

clean-all

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.

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.

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.