Operation not permitted - bs_fetch:atomic_write_cache_file:chmod (Errno::EPERM) #353
Comments
|
Seems like the common theme in all these reports is multiple processes using the same cache, which hints at a race condition. If I'm right, as a workaround you can set a different If that works, I'd be interested to know. |
|
I have a similar issue: the containers starting resque for background job processing fail to start. @casperisfine Setting |
|
Thanks a lot for letting me know @arbesulo, that seem to confirm my suspicion, I might be able to develop a blind fix. |
|
Ok, so I suspect it's because the two docker containers don't have the same UID, so the In the vast majority of the cases, the two process will read each others cache fine, but in rare race conditions situations, they might both try to generate a missing cache, and overwrite each others, causing one process to try to I see a few solutions out of this:
@arbesulo and @dmolesUC I'd appreciate if one of you could confirm my theory. Could you confirm wether |
|
Out of curiosity, I just studied how python's does it with it's After modifying the script and running it as a regular users, the cache was unchanged, so I'm pretty sure Python simply gracefully recover from this class of problem, which I admit kind makes sense. The performance would be impacted, and the user probably wouldn't know why, but the failure mode is somewhat more controlled. |
I just put |
|
Urk, here goes my theory. So both process are Is your error |
|
I pushed a branch with a change that I believe to fix this class of issues. I'd appreciate if people who experience this issue could use that branch for a while and tell me in a few days wether they've seen the issue: gem 'bootsnap', github: 'Shopify/bootsnap', branch: 'handle-race-conditions' |
|
I'll give it a try. Thanks a lot for the quick fix! |
|
👍 I'll do the same on my end. I had a fairly reproducible case with our 24-thread Mac Pro running |
|
No problems so far with the fix in that branch |
|
The branch fixed the first issue, but i have now that one: |
|
Hum, interesting. I suppose we need to be resilient to failed reads as well. I'll try another change. |
|
@navidemad I pushed 503e9d5 in that same branch. Thanks a lot for testing these patches. |
|
Working so far with your last patch 💯 |
|
Great to hear! Let's keep this issue open for now, if no-one report any more errors with this branch I'll cut a release around mid next week. |
|
I just ran into this issue on Rails 6.1.3.1 and Ruby 3.0.1 with Bootsnap 1.7.2. |
For the previous commit, I stole the procfile from https://github.com/davidharting/tweet-scheduler/blob/dd04f8cced5e5fa7820adfb604231ded44dc4d46/Procfile For this, I ran into Shopify/bootsnap#353
* Docker container for dev environment was upgraded to Ruby 3.0.1. So updated Gemfile ruby version. * After that, I ran into Shopify/bootsnap#353, so updated Bootsnap. * Updated Profile to run migrations and to use bundler / binstubs
|
I just released a |
|
🎉 Awesome job @casperisfine! We've been running your branch hard for the last week and it's been rock solid. Thanks again for resolving this and releasing a new version so quickly. 👍 |
|
Sorry to be late to my own party, but thanks, @casperisfine! |
I'm running a Docker stack with two instances of the same Rails app: one,
updaterthat just runsrails setupand exits, and another,appthat's the application proper, and I'm often but not always seeing variations on the above error, but only when my stack mounts the current working directory (i.e. my development checkout) to the Rails root directory.Probably related to #177 and possibly #262, but still present with Bootsnap 1.7.3 (Rails 6.0.3.6). It doesn't always seem to happen at the same point in the startup sequence, and it doesn't always happen with both instances.
Example 1 (
updateronly):Example 2 (
appandupdaterboth):The text was updated successfully, but these errors were encountered: