Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cleanup isn't concurrent-safe #3242

Closed
ptarjan opened this issue Jun 21, 2016 · 2 comments · Fixed by #3975
Closed

cleanup isn't concurrent-safe #3242

ptarjan opened this issue Jun 21, 2016 · 2 comments · Fixed by #3975

Comments

@ptarjan
Copy link
Contributor

ptarjan commented Jun 21, 2016

Expected behavior

I can run many rubocop processes at the same time and they all finish.

Actual behavior

If two rubocop processes finish running at the same time, one of them can clean up the cache directory, and the other throws with:

No such file or directory @ rb_file_s_mtime - /cache/rubocop_cache/99c3ac6602c51029823c15c9106045a23955950d/rubocop_cache/02639da205e170093bd901c9c3d16645/_/00ab6b745135000518d35d28f2606f01
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/result_cache.rb:35:in `mtime'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/result_cache.rb:35:in `block in cleanup'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/result_cache.rb:35:in `each'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/result_cache.rb:35:in `sort_by'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/result_cache.rb:35:in `cleanup'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/runner.rb:67:in `inspect_files'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/runner.rb:35:in `run'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/lib/rubocop/cli.rb:30:in `run'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/bin/rubocop:14:in `block in <top (required)>'
21:15:35 /usr/lib/rbenv/versions/2.1/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
21:15:35 /src/vendor/bundle/ruby/2.1.0/gems/rubocop-0.40.0/bin/rubocop:13:in `<top (required)>'
21:15:35 /src/vendor/bundle/ruby/2.1.0/bin/rubocop:23:in `load'
21:15:35 /src/vendor/bundle/ruby/2.1.0/bin/rubocop:23:in `<main>'

Steps to reproduce the problem

$ touch /tmp/a.rb
$ for i in `seq 200`; do rubocop /tmp/a.rb & done

One of them should error out int result_cache.rb:35.

RuboCop version

$ rubocop -V
0.40.0 (using Parser 2.3.1.0, running on ruby 2.1.2 x86_64-darwin15.0)
@bbatsov
Copy link
Collaborator

bbatsov commented Jun 27, 2016

Guess we can write some marker file or something to prevent this from happening. Other ideas are welcome as well.

@jonas054
Copy link
Collaborator

jonas054 commented Jul 3, 2016

Another way would be to ignore Errno::ENOENT exceptions we get on the lines

        sorted = files.sort_by { |path| File.mtime(path) }
        remove_files(sorted, dirs, remove_count, verbose)

We know the files were there an instant ago, so they were most likely removed by another rubocop process, which is something we can accept.

mikegee added a commit to mikegee/rubocop that referenced this issue Jan 27, 2017
We already ignore `Errno::ENOENT` during the removal, but `File.mtime`
might raise too.
bbatsov pushed a commit that referenced this issue Jan 28, 2017
…3975)

We already ignore `Errno::ENOENT` during the removal, but `File.mtime`
might raise too.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants