Error "block in create_with_logging_context"

Infos:

  • Used Zammad version: 3.6
  • Used Zammad installation source: Docker-Compose
  • Operating system: Docker
  • Browser + version: Google Chrome 88.x

Expected behavior:

  • Rebuilding the Docker-Compose containers leads to a normally acting and functioning system.

Actual behavior:

  • Only an error page is displayed, logging in is not possible.

Backtrace:
railsserver_1 | I, [2021-03-18T12:16:01.074389 #1-46968450359900] INFO – : Started GET “/” for XXX.XXX.XXX.XXX at 2021-03-18 12:16:01 +0000
railsserver_1 | F, [2021-03-18T12:16:01.076483 #1-46968450359900] FATAL – :
railsserver_1 | F, [2021-03-18T12:16:01.077336 #1-46968450359900] FATAL – : NoMethodError (undefined method silence' for #<Logger:0x0000556f60150408>): railsserver_1 | F, [2021-03-18T12:16:01.077367 #1-46968450359900] FATAL -- : railsserver_1 | F, [2021-03-18T12:16:01.077384 #1-46968450359900] FATAL -- : activerecord-session_store (2.0.0) lib/action_dispatch/session/active_record_store.rb:119:in get_session_model’
railsserver_1 | activerecord-session_store (2.0.0) lib/action_dispatch/session/active_record_store.rb:147:in find_session' railsserver_1 | rack (2.2.3) lib/rack/session/abstract/id.rb:314:in load_session’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/session/abstract_store.rb:46:in block in load_session' railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/session/abstract_store.rb:54:in stale_session_check!’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/session/abstract_store.rb:46:in load_session' railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/request/session.rb:227:in load!’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/request/session.rb:219:in load_for_read!' railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/request/session.rb:92:in []’
railsserver_1 | omniauth-twitter (1.4.0) lib/omniauth/strategies/twitter.rb:75:in callback_path' railsserver_1 | omniauth (1.9.1) lib/omniauth/strategy.rb:256:in on_callback_path?’
railsserver_1 | omniauth (1.9.1) lib/omniauth/strategy.rb:244:in on_auth_path?' railsserver_1 | omniauth (1.9.1) lib/omniauth/strategy.rb:184:in call!’
railsserver_1 | omniauth (1.9.1) lib/omniauth/strategy.rb:169:in call' railsserver_1 | omniauth (1.9.1) lib/omniauth/builder.rb:45:in call’
railsserver_1 | rack (2.2.3) lib/rack/tempfile_reaper.rb:15:in call' railsserver_1 | rack (2.2.3) lib/rack/etag.rb:27:in call’
railsserver_1 | rack (2.2.3) lib/rack/conditional_get.rb:27:in call' railsserver_1 | rack (2.2.3) lib/rack/head.rb:12:in call’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/http/content_security_policy.rb:18:in call' railsserver_1 | rack (2.2.3) lib/rack/session/abstract/id.rb:266:in context’
railsserver_1 | rack (2.2.3) lib/rack/session/abstract/id.rb:260:in call' railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/cookies.rb:670:in call’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/callbacks.rb:28:in block in call' railsserver_1 | activesupport (5.2.4.5) lib/active_support/callbacks.rb:98:in run_callbacks’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/callbacks.rb:26:in call' railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/debug_exceptions.rb:61:in call’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/show_exceptions.rb:33:in call' railsserver_1 | railties (5.2.4.5) lib/rails/rack/logger.rb:38:in call_app’
railsserver_1 | railties (5.2.4.5) lib/rails/rack/logger.rb:28:in call' railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/remote_ip.rb:81:in call’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/request_id.rb:27:in call' railsserver_1 | rack (2.2.3) lib/rack/method_override.rb:24:in call’
railsserver_1 | rack (2.2.3) lib/rack/runtime.rb:22:in call' railsserver_1 | activesupport (5.2.4.5) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in call’
railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/executor.rb:14:in call' railsserver_1 | actionpack (5.2.4.5) lib/action_dispatch/middleware/static.rb:127:in call’
railsserver_1 | rack (2.2.3) lib/rack/sendfile.rb:110:in call' railsserver_1 | railties (5.2.4.5) lib/rails/engine.rb:524:in call’
railsserver_1 | puma (3.12.6) lib/puma/configuration.rb:227:in call' railsserver_1 | puma (3.12.6) lib/puma/server.rb:706:in handle_request’
railsserver_1 | puma (3.12.6) lib/puma/server.rb:476:in process_client' railsserver_1 | puma (3.12.6) lib/puma/server.rb:334:in block in run’
railsserver_1 | puma (3.12.6) lib/puma/thread_pool.rb:135:in block in spawn_thread' railsserver_1 | logging (2.2.2) lib/logging/diagnostic_context.rb:474:in block in create_with_logging_context’

Steps to reproduce the behavior:

  • I really don’t know

My steps to fix this behavior:

  • Added “export RAILS_LOG_TO_STDOUT=true” to setup.sh and docker-entrypoint.sh, to trigger Line 89 in the production.rb (if ENV[‘RAILS_LOG_TO_STDOUT’].present?)

This obviously seems to be just a temporary fix. However, I am unsure if it’s a problem on my end or if something in this regard has changed elsewhere.
That’s why I decided to create this community entry.

Thank you very much.

With kind regards
Lena

Please provide the used tag as well, other wise it’s impossible to help you.
The containers on the technical layer may change during a version.

Hello MrGeneration,
Thank you very much for your answer.

Unfortunately I don’t use an official image as we run all data on a central database and behind an Apache, so I have adapted a few things, but have always strongly followed your documentation.

This sounds like a typical excuse: but two weeks ago the rebuild worked without any problems :slight_smile: . As far as I know, nothing has been changed on our system, only the more recent stable branch of the zammad git repository has changed. Maybe I should always stick to one branch in the future.

I don’t expect you to look at my particular case, but I just wanted to point out my problem in case other people get this backtrace / error message as well.

Nevertheless, many thanks for your great product.

I’m seeing the same issue (Syslog support broken?) if syslog is enabled on a source installation using the stable branch (currently 3.6.x)

Looks like it’s related to the update of activerecord-session_store.
Any idea how to fix it? NoMethodError: undefined method silence for Logger after 2.0.0 upgrade · Issue #176 · rails/activerecord-session_store · GitHub

With “3.6.0-67” I’m getting an error that nginx doesn’t have permission to bind to 0.0.0.0:80.
When I edit /contrib/nginx/zammad.conf to listen to 8080 after bringing up the stack the nginx container starts and I see the same issue as @Lena or @saz

this is a known issue, please see: Nginx container stops after starting every container · Issue #192 · zammad/zammad-docker-compose · GitHub
don’t think it’s related to the syslog issue

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.