I am in the process of upgrading a Rails 4.2 application to Rails 5.0. We are using capybara-minitest-rails for our feature tests. All of the feature tests are currently timing out. We are using ruby 2.4.2p198.
When using gdb to inspect the process I got the following output:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
I added ActionDispatch::DebugLocks middleware which gave me the following on /rails/locks
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/activerecord-5.0.6/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `async_exec'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/activerecord-5.0.6/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `block in exec_no_cache'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/activerecord-5.0.6/lib/active_record/connection_adapters/abstract_adapter.rb:590:in `block in log'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/activesupport-5.0.6/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/activerecord-5.0.6/lib/active_record/connection_adapters/abstract_adapter.rb:583:in `log'
...
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/railties-5.0.6/lib/rails/engine.rb:522:in `call'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/puma-3.10.0/lib/puma/configuration.rb:225:in `call'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/puma-3.10.0/lib/puma/server.rb:605:in `handle_request'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/puma-3.10.0/lib/puma/server.rb:437:in `process_client'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/puma-3.10.0/lib/puma/server.rb:301:in `block in run'
/home/user/.rvm/gems/ruby-2.4.2@jilt/gems/puma-3.10.0/lib/puma/thread_pool.rb:120:in `block in spawn_thread'
I have swapped out puma with thin and I still get the same issue. Trying to force puma to run with 1 process and 1 thread, as well as setting eager_load=true have yielded no positive results.