I have a self hosted gitlab CE server ,running fine for a year now.
Just a few days ago this error keep poping up
Please help me fix this. I don’t know why the gitaly socket just keep delete and create every time
Gitlab Version: 12.0.12 (ce125b970e4)
OS: Centos 7 3.10.0-1160.11.1.el7.x86_64
Gitlab::Git::CommandError (14:all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /tmp/gitaly-ruby289404666/socket.1: connect: no such file or directory"):
lib/gitlab/git/wraps_gitaly_errors.rb:13:in `rescue in wrapped_gitaly_errors'
lib/gitlab/git/wraps_gitaly_errors.rb:6:in `wrapped_gitaly_errors'
lib/gitlab/git/blob.rb:83:in `batch_lfs_pointers'
lib/extracts_path.rb:149:in `lfs_blob_ids'
app/controllers/projects/application_controller.rb:98:in `block in allow_gitaly_ref_name_caching'
lib/gitlab/gitaly_client.rb:309:in `allow_ref_name_caching'
app/controllers/projects/application_controller.rb:97:in `allow_gitaly_ref_name_caching'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:445:in `set_session_storage'
lib/gitlab/i18n.rb:55:in `with_locale'
lib/gitlab/i18n.rb:61:in `with_user_locale'
app/controllers/application_controller.rb:439:in `set_locale'
lib/gitlab/middleware/multipart.rb:103:in `call'
lib/gitlab/request_profiler/middleware.rb:16:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/correlation_id.rb:16:in `block in call'
lib/gitlab/middleware/correlation_id.rb:15:in `call'
lib/gitlab/middleware/read_only/controller.rb:40:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:26:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:29:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
Related
Issue summary
I am getting this error whenever I try to start the development server
Expected behavior
Shopify node serve should run the development server
Actual behavior
What actually happens?
C:\Users\HP-PC\Desktop\myfirsttest>shopify node serve
X An unexpected error occured.
To ]8;;https://github.com/Shopify/shopify-cli/issues/new\submit an issue]8;;\ include the stack trace.
C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/process_supervision.rb:40:in `Integer': invalid value for Integer(): "\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000" (ArgumentError)
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/process_supervision.rb:40:in `for_ident'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/process_supervision.rb:127:in `running?'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/process_supervision.rb:62:in `start'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/tunnel.rb:189:in `start_ngrok'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/tunnel.rb:68:in `start'
from C:/Ruby30-x64/lib/ruby/3.0.0/forwardable.rb:238:in `start'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/project_types/node/commands/serve.rb:16:in `call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/sub_command.rb:13:in `call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/command.rb:19:in `call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/core/executor.rb:17:in `block (2 levels) in call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:37:in `block (2 levels) in with_logging'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-ui/lib/cli/ui/stdout_router.rb:169:in `with_id'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:36:in `block in with_logging'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-ui/lib/cli/ui.rb:176:in `log_output_to'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:35:in `with_logging'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/core/executor.rb:16:in `block in call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:45:in `block (2 levels) in with_traps'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:51:in `twrap'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:44:in `block in with_traps'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:51:in `twrap'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/executor.rb:43:in `with_traps'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/core/executor.rb:15:in `call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/core/entry_point.rb:24:in `block in call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/core/monorail.rb:30:in `log'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/lib/shopify_cli/core/entry_point.rb:23:in `call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/bin/shopify:37:in `block (2 levels) in <top (required)>'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/error_handler.rb:75:in `handle_abort'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/vendor/deps/cli-kit/lib/cli/kit/error_handler.rb:21:in `call'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/bin/shopify:36:in `block in <top (required)>'
from C:/Ruby30-x64/lib/ruby/gems/3.0.0/gems/shopify-cli-2.6.6/bin/shopify:47:in `<top (required)>'
from C:/Ruby30-x64/bin/shopify:23:in `load'
from C:/Ruby30-x64/bin/shopify:23:in `<main>'
After an unsuccessful upgrade, some of the repositories broke, when trying to delete the repository as standard way, it shows Error 500 ("500 Whoops, something went wrong on our end.
Try refreshing the page, or going back and attempting the action again. Please contact your GitLab administrator if this problem persists. Go back"). How I can delete the repository on the ubuntu server?
In production.log I found such entries about my attempt to delete the repository:
Started DELETE "/student100675/anagrams" for 217.MY.IP.HERE at 2021-11-09 11:30:30 +0200
Processing by ProjectsController#destroy as HTML
Parameters: {"authenticity_token"=>"[FILTERED]", "namespace_id"=>"student100675", "id"=>"anagrams"}
Completed 500 Internal Server Error in 60ms (ActiveRecord: 3.5ms | Elasticsearch: 0.0ms | Allocations: 9529)
OpenSSL::Cipher::CipherError ():
lib/gitlab/crypto_helper.rb:28:in aes256_gcm_decrypt' app/models/concerns/token_authenticatable_strategies/encryption_helper.rb:18:in decrypt_token'
app/models/concerns/token_authenticatable_strategies/encrypted.rb:45:in get_token' app/models/concerns/token_authenticatable_strategies/base.rb:32:in ensure_token'
app/models/concerns/token_authenticatable_strategies/encrypted.rb:32:in ensure_token' app/models/concerns/token_authenticatable.rb:43:in block in add_authentication_token_field'
app/services/projects/destroy_service.rb:10:in async_execute' app/controllers/projects_controller.rb:162:in destroy'
app/controllers/application_controller.rb:485:in set_current_admin' lib/gitlab/session.rb:11:in with_session'
app/controllers/application_controller.rb:476:in set_session_storage' lib/gitlab/i18n.rb:105:in with_locale'
lib/gitlab/i18n.rb:111:in with_user_locale' app/controllers/application_controller.rb:470:in set_locale'
app/controllers/application_controller.rb:464:in set_current_context' lib/gitlab/middleware/speedscope.rb:13:in call'
lib/gitlab/request_profiler/middleware.rb:17:in call' lib/gitlab/jira/middleware.rb:19:in call'
lib/gitlab/middleware/go.rb:20:in call' lib/gitlab/etag_caching/middleware.rb:21:in call'
lib/gitlab/middleware/multipart.rb:172:in call' lib/gitlab/middleware/read_only/controller.rb:50:in call'
lib/gitlab/middleware/read_only.rb:18:in call' lib/gitlab/middleware/same_site_cookies.rb:27:in call'
lib/gitlab/middleware/handle_malformed_strings.rb:21:in call' lib/gitlab/middleware/basic_health_check.rb:25:in call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in call' lib/gitlab/middleware/request_context.rb:21:in call'
config/initializers/fix_local_cache_middleware.rb:11:in call' lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in call'
lib/gitlab/middleware/sidekiq_web_static.rb:20:in call' lib/gitlab/metrics/requests_rack_middleware.rb:74:in call'
lib/gitlab/middleware/release_env.rb:12:in `call'
I'm my case was fixed after restoring the /etc/gitlab/gitlab-secrets.json
More refs:
https://forum.gitlab.com/t/after-updating-from-version-gitlab-11-8-10-breaks-runners-ci/30037
It was the problem with hashed and legacy repositories, I solved it with this tip:
gitlab-rails console
projects = Project.where(repository_read_only: true)
projects.each do |p|
p.update!(repository_read_only:nil)
end
gitlab-rake gitlab:storage:migrate_to_hashed
gitlab-ctl reconfigure
I tried all two versions of what’s written here and they didn’t help me
The only thing that helped me is a complete reinstallation of gitlab
before deleting everything I copied all the repositories to my local disk and all users
after installation created new repositories and push an existing Git repository
Another way if you have a "read-only" legacy repositories:
Reset runner registration tokens
https://docs.gitlab.com/ee/raketasks/backup_restore.html#when-the-secrets-file-is-lost
sudo gitlab-rails console
Project.all.find_each { |project| project.update!(repository_read_only: false) }
I'm trying to set up a perpetually 1 day old clone of a gitlab server. The gitlab version on both machines 12.4.1-ce.0. There's a daily crontab for the following:
gitlab-rake GZIP_RSYNCABLE=yes gitlab:backup:create
Then it transfers the backup to my clone machine and it runs
gitlab-ctl stop unicorn && gitlab-ctl stop sidekiq && gitlab-rake gitlab:backup:restore BACKUP=most_recent force=yes --trace && gitlab-ctl restart
All of the infrastructure there works and I'm happy with it, but then during the restore, many many repos are failing to restore, throwing one of two messages for one of two types of restores:
repos larger than ~800MB
Error: 4:Deadline Exceeded
all wikis
Error 13:CreateRepositoryFromBundle: cmd wait failed: exit status 128
Searching around online said that this is probably a gitaly timeout issue, so I changed the default timeout from 55s to 475s, the fast from 10s to 30s, and the medium from 30s to 115s, but that made no difference.
At the end of the restore, I get this message:
2019-11-20 12:46:14 -0500 -- Restoring lfs objects ...
2019-11-20 12:46:14 -0500 -- done
** Invoke gitlab:backup:registry:restore (first_time)
** Invoke gitlab_environment
** Execute gitlab:backup:registry:restore
2019-11-20 12:46:14 -0500 -- Restoring container registry images ...
rake aborted!
Backup::Error: Backup failed
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/files.rb:81:in `run_pipeline!'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/files.rb:44:in `restore'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:234:in `block (4 levels) in <top (required)>'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `block in execute'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `each'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `execute'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:214:in `block in invoke_with_call_chain'
/opt/gitlab/embedded/lib/ruby/2.6.0/monitor.rb:230:in `mon_synchronize'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:194:in `invoke_with_call_chain'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:183:in `invoke'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:71:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `block in execute'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `each'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `execute'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:214:in `block in invoke_with_call_chain'
/opt/gitlab/embedded/lib/ruby/2.6.0/monitor.rb:230:in `mon_synchronize'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:194:in `invoke_with_call_chain'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/task.rb:183:in `invoke'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:160:in `invoke_task'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:116:in `each'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:116:in `block in top_level'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:125:in `run_with_threads'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:110:in `top_level'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:83:in `block in run'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:186:in `standard_exception_handling'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/lib/rake/application.rb:80:in `run'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rake-12.3.3/exe/rake:27:in `<top (required)>'
/opt/gitlab/embedded/bin/rake:23:in `load'
/opt/gitlab/embedded/bin/rake:23:in `<top (required)>'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/cli/exec.rb:74:in `load'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/cli/exec.rb:74:in `kernel_load'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/cli/exec.rb:28:in `run'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/cli.rb:463:in `exec'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/cli.rb:27:in `dispatch'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/cli.rb:18:in `start'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/exe/bundle:30:in `block in <top (required)>'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/exe/bundle:22:in `<top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'
Tasks: TOP => gitlab:backup:registry:restore
I'm not even sure if that's because of the same problem, or if it's entirely unrelated. Anyone know what's wrong, or where I can start looking next?
In your blog post: http://pakyow.com/blog/2015/03/24/ui-intro
I was following along and received an error when configuring the default route for the view partial :form with an empty binding set.
view.partial(:form).scope[:message].bind({})
When refreshing the browser, it gave me an error below.
Not sure how to resolve this or what dependencies I need to check.
Server Error:
The error originated on line 104 of 'C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-presenter-0.9.1/pakyow-presenter/lib/presenter/view.rb' and generated the following stack trace:
wrong number of arguments (0 for 1)
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-presenter-0.9.1/pakyow-presenter/lib/presenter/view.rb:104:in `scope'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-presenter-0.9.1/pakyow-presenter/lib/presenter/view_context.rb:44:in `method_missing'
C:/Users/Anna/Documents/wallyou/app/lib/routes.rb:7:in `block (2 levels) in <top (required)>'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:102:in `instance_exec'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:102:in `block in call_fns'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:102:in `each'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:102:in `call_fns'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:140:in `block in trampoline'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:139:in `catch'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:139:in `trampoline'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/router.rb:46:in `perform'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/app.rb:245:in `block in process'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/app.rb:242:in `catch'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/app.rb:242:in `process'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/app.rb:223:in `call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/middleware/reloader.rb:10:in `call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/middleware/logger.rb:118:in `block in call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/middleware/logger.rb:129:in `time'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/middleware/logger.rb:116:in `call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/pakyow-core-0.9.1/pakyow-core/lib/core/middleware/static.rb:20:in `call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/rack-1.6.1/lib/rack/methodoverride.rb:22:in `call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/rack-1.6.1/lib/rack/builder.rb:153:in `call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/puma-2.11.2/lib/puma/server.rb:507:in `handle_request'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/puma-2.11.2/lib/puma/server.rb:375:in `process_client'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/puma-2.11.2/lib/puma/server.rb:262:in `block in run'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/puma-2.11.2/lib/puma/thread_pool.rb:104:in `call'
C:/Ruby200/lib/ruby/gems/2.0.0/gems/puma-2.11.2/lib/puma/thread_pool.rb:104:in `block in spawn_thread'
scope should be a function call, like this:
view.partial(:form).scope(:message).bind({})
The way you have it, message is wrapped in square brackets.
I'm getting this error on a pretty regular basis: ThreadError: deadlock; recursive locking. I read that if using Unicorn (which I am) that Rack::Lock is not needed. I can remove it by adding config.middleware.delete "Rack::Lock" to application.rb.
Does anyone have opinions on if it is safe to remove Rack::Lock from my production app?
For reference, the common trace:
…dor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/lock.rb:14:in `lock'
…dor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/lock.rb:14:in `call'
…bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/deflater.rb:13:in `call'
…/bundle/ruby/2.0.0/gems/rack-ssl-1.3.3/lib/rack/ssl.rb:27:in `call'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in `forward'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:245:in `fetch'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:185:in `lookup'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:66:in `call!'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in `call'
…by/2.0.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:552:in `process_client'
…icorn-worker-killer-0.4.2/lib/unicorn/worker_killer.rb:51:in `process_client'
…icorn-worker-killer-0.4.2/lib/unicorn/worker_killer.rb:124:in `process_client'
…by/2.0.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:632:in `worker_loop'
…by/2.0.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:500:in `spawn_missing_workers'
…by/2.0.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:142:in `start'
Ok, I removed config.middleware.delete "Rack::Lock" about a week ago and all seems to be working ok. The error is gone and removing Rack::Lock has caused no issues.