فشل Sidekiq في البدء بعد Zeitwerk على Docker dev

averi · 2 أكتوبر 2019، 10:44ص

قمنا مؤخرًا بالترقية إلى الإصدار 2.4.0.beta5 من الإصدار 2.4.0.beta4، وفشل Sidekiq في البدء مع ظهور تتبع الأخطاء التالي:

> $ bundle exec sidekiq -C config/sidekiq.yml
> uninitialized constant SiteSetting::SiteSettingExtension
> /discourse/app/models/site_setting.rb:5:in `<class:SiteSetting>'
> /discourse/app/models/site_setting.rb:3:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:23:in `require'
> /discourse/vendor/bundle/ruby/2.5.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:23:in `require'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/dependencies/interlock.rb:14:in `block in loading'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/concurrency/share_lock.rb:151:in `exclusive'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/dependencies/interlock.rb:13:in `loading'
> /discourse/config/initializers/004-message_bus.rb:120:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:667:in `block in load_config_initializer'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/notifications.rb:182:in `instrument'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:666:in `load_config_initializer'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:624:in `block (2 levels) in <class:Engine>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:623:in `each'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:623:in `block in <class:Engine>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `instance_exec'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `run'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:61:in `block in run_initializers'
> /usr/local/lib/ruby/2.5.0/tsort.rb:228:in `block in tsort_each'
> /usr/local/lib/ruby/2.5.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
> /usr/local/lib/ruby/2.5.0/tsort.rb:422:in `block (2 levels) in each_strongly_connected_component_from'
> /usr/local/lib/ruby/2.5.0/tsort.rb:431:in `each_strongly_connected_component_from'
> /usr/local/lib/ruby/2.5.0/tsort.rb:421:in `block in each_strongly_connected_component_from'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:50:in `each'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:50:in `tsort_each_child'
> /usr/local/lib/ruby/2.5.0/tsort.rb:415:in `call'
> /usr/local/lib/ruby/2.5.0/tsort.rb:415:in `each_strongly_connected_component_from'
> /usr/local/lib/ruby/2.5.0/tsort.rb:349:in `block in each_strongly_connected_component'
> /usr/local/lib/ruby/2.5.0/tsort.rb:347:in `each'
> /usr/local/lib/ruby/2.5.0/tsort.rb:347:in `call'
> /usr/local/lib/ruby/2.5.0/tsort.rb:347:in `each_strongly_connected_component'
> /usr/local/lib/ruby/2.5.0/tsort.rb:226:in `tsort_each'
> /usr/local/lib/ruby/2.5.0/tsort.rb:205:in `tsort_each'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:60:in `run_initializers'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/application.rb:363:in `initialize!'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/railtie.rb:190:in `public_send'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/railtie.rb:190:in `method_missing'
> /discourse/config/environment.rb:7:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.7/lib/sidekiq/cli.rb:288:in `boot_system'
> /discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.7/lib/sidekiq/cli.rb:46:in `run'
> /discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.7/bin/sidekiq:12:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/bin/sidekiq:23:in `load'
> /discourse/vendor/bundle/ruby/2.5.0/bin/sidekiq:23:in `<top (required)>'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `load'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `kernel_load'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:28:in `run'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:463:in `exec'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:27:in `dispatch'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:18:in `start'
> /usr/local/bin/bundle:30:in `block in <main>'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
> /usr/local/bin/bundle:22:in `<main>'

هل هناك أي توجيهات حول أين يجب البحث بعد ذلك؟ شكرًا!

Falco · 2 أكتوبر 2019، 12:14م

هذه ليست تثبيتًا اتبع دليلنا الرسمي، لذا لا يمكننا مساعدتك كثيرًا.

averi · 2 أكتوبر 2019، 12:27م

نقوم حاليًا بتشغيل Discourse على OpenShift، لذا من المؤكد أنه ليس تثبيتًا قياسيًا. سأراجع الدليل الرسمي وأرى ما إذا كان قد فاتني أي شيء في النشر الحالي، شكرًا لك.

azawawi · 2 أكتوبر 2019، 12:39م

في الواقع، حتى أمر Docker التالي يُحدث نفس تتبع المكدس في جهاز Vagrant الخاص بـ Discourse عبر VirtualBox:

vagrant ssh -c '(cd ~/discourse && sudo bin/docker/sidekiq)'

Falco · 2 أكتوبر 2019، 12:42م

هل أنت متأكد من ذلك؟ لا يحتوي الدليل الرسمي على أي شيء يتعلق بالبدء اليدوي لـ sidekiq، ولا يوجد مجلد /home/discourse فيه.

هل تقوم بتشغيل تثبيت تطويري في بيئة الإنتاج ؟

azawawi · 2 أكتوبر 2019، 12:45م

أنا أستخدم أوامر Docker لاختبار وتطوير إضافات Discourse.

النص البرمجي الآخر الذي أستخدمه حاليًا هو:

# مسح ذاكرة التخزين المؤقت المؤقتة لـ Discourse وتشغيل Rails للتطوير
vagrant ssh -c '(rm -rf ~/discourse/tmp/cache)'
vagrant ssh -c '(cd ~/discourse && sudo bin/docker/rails s)'

azawawi · 2 أكتوبر 2019، 12:47م

بالطبع لا

azawawi · 2 أكتوبر 2019، 12:50م

@Falco أعتقد أن الأمر مرتبط بـ

ما رأيك؟

Falco · 2 أكتوبر 2019، 12:51م

ربما يكون كذلك. لم يسرّ الأمر أنك لم تذكر أن هذا إعداد تطويرك وليس بيئة تطوير.

إذًا، هل تقول إن إعدادنا الحالي للـ Docker للتطوير معطل؟

azawawi · 2 أكتوبر 2019، 12:52م

نعم، يبدو الأمر كذلك.

azawawi · 2 أكتوبر 2019، 12:59م

إلغاء هذا الالتزام (commit) يعيد تشغيل sidekiq مرة أخرى.

Falco · 2 أكتوبر 2019، 1:11م

يبدو أن هذا من نصيبك @kris.kotlarek

kris.kotlarek · 2 أكتوبر 2019، 11:32م

حسنًا، أعرف ما حدث هنا، الخطأ مني. لقد أزلت الكثير من require_dependency لأنها لم تعد ضرورية عند استخدام مُحمّل Zeitwerk التلقائي.

ومع ذلك، في ملف application.rb لدينا هذا الكود:

if !Sidekiq.server?
  config.autoload_paths += Dir["#{config.root}/lib"]
end

وهو ما يعني أن Sidekiq لا يبحث في مجلد lib عن التبعيات، بل نحدد بشكل صريح ما هو مطلوب في ملفات معينة.

يمكنني إعادة require_dependency للملفات التي يستخدمها Sidekiq، أو إزالة هذا الشرط في application.rb.

أظن أننا استخدمنا استدعاء require الصريح هذا لتوفير بعض الذاكرة للعاملين (workers)، لذا ربما ينبغي لنا اتباع هذا المسار. سأعيد require_dependency.

@sam ما رأيك؟

sam · 2 أكتوبر 2019، 11:36م

يجب إزالة هذا الشرط؛ لا أحبّه لأنك لا تعرف ما إذا كانت عمليتك ستتحول إلى Sidekiq أم لا. في عمليات النشر لدينا: unicorn master → fork → sidekiq worker. وعند لحظة الـ fork، كان ملف application.rb قد تم تحليله بالفعل.

azawawi · 3 أكتوبر 2019، 7:18ص

@kris.kotlarek شكرًا لك على الإصلاح. يعمل Sidekiq الآن جنبًا إلى جنب مع الإضافات الرسمية لمنصة Discourse .

معظم الإضافات التابعة لجهات خارجية التي تحتوي على مهام لا تعمل حاليًا . وعلى الأرجح أن السبب هو عدم تطبيق التعديل التالي على فئات Jobs:: الخاصة بها.

الإضافات التابعة لجهات خارجية المعطلة

github.com/gdpelican/babble

app/jobs/regular/babble_post_alert.rb

master


      
          module Jobs
            class BabblePostAlert < ::Jobs::Base
              def execute(args)
                return unless post = Post.find_by(id: args[:post_id])
                return unless post.topic&.archetype == Archetype.chat
                Babble::PostAlerter.new.after_save_post(post)
              end
            end
          end

github.com/procourse/procourse-static-pages

app/jobs/onceoff/migrate_static_pages_plugin.rb

master


      
          module Jobs
            class MigrateStaticPagesPlugin < ::Jobs::Onceoff
              # Migrate content from dl_static_pages name to procourse_static_pages
              def execute_onceoff(args)
                  dl_page_presence = PluginStoreRow.where(plugin_name: "dl_static_pages").exists?
                  if dl_page_presence
                      # Migrate the page content rows
                      PluginStoreRow.where(plugin_name: 'dl_static_pages')
                      .find_each do |row|
                          PluginStore.set("procourse_static_pages", row.key, row.value)
                          row.destroy # clean up dl_static_pages row
                      end

github.com/discourse/discourse-whos-online

plugin.rb

main


      
          # frozen_string_literal: true
          
          # name: discourse-whos-online
          # about: Display a list of online users at the top of the screen
          # meta_topic_id: 52345
          # version: 2.0
          # authors: David Taylor
          # url: https://github.com/discourse/discourse-whos-online
          
          enabled_site_setting :whos_online_enabled
          
          register_asset "stylesheets/whos_online.scss"
          
          after_initialize do
            module ::DiscourseWhosOnline
              CHANNEL_NAME = "/whos-online/online"
            end
          
            register_presence_channel_prefix("whos-online") do |channel_name|
              if channel_name == "/whos-online/online"
                config = PresenceChannel::Config.new(timeout: SiteSetting.whos_online_active_timeago * 60)
                if SiteSetting.whos_online_display_public
                  config.public = true
                else
                  config.allowed_group_ids = [::Group::AUTO_GROUPS[:trust_level_0]]
                end
                config.count_only = SiteSetting.whos_online_count_only
                config
              end
            end
          
            on(:user_seen) do |user|
              hidden = false
              hidden ||= user.user_option.hide_presence if defined?(user.user_option.hide_presence)
              hidden ||= user.id < 0
              next if hidden
              PresenceChannel.new(DiscourseWhosOnline::CHANNEL_NAME).present(
                user_id: user.id,
                client_id: "seen",
              )
            rescue PresenceChannel::InvalidAccess
            end
          
            add_to_serializer(
              :site,
              :whos_online_state,
              include_condition: -> do
                @whos_online_channel ||= PresenceChannel.new(DiscourseWhosOnline::CHANNEL_NAME)
                @whos_online_channel.can_view?(user_id: scope.user&.id)
              end,
            ) do
              @whos_online_channel ||= PresenceChannel.new(DiscourseWhosOnline::CHANNEL_NAME)
              PresenceChannelStateSerializer.new(@whos_online_channel.state, root: nil)
            end
          end

kris.kotlarek · 3 أكتوبر 2019، 11:07م

أنت محق، فكل من Jobs::Onceoff و Jobs::Base و Jobs::Scheduled تتطلب الآن استخدام ::

لقد قمت بإصلاح discourse-whos-online وأنشأت طلبات دمج (pull requests) لملحقات أخرى:

azawawi · 4 أكتوبر 2019، 5:13ص

@kris.kotlarek شكرًا جزيلاً . لقد اطّلعت على منشورك الخاص بـ zeitwork auto-loader. هل هناك خطة لتفعيل ميزة إعادة تحميل تلقائية لإضافات التطوير لتسريع عملية تطوير الإضافات.

kris.kotlarek · 4 أكتوبر 2019، 5:33ص

لا تزال هناك أماكن تحتوي على require أو require_dependency، لكن العديد منها قد أُزيل.

أعتقد أن كود الإضافة يجب أن يتم إعادة تحميله تلقائيًا الآن دون مشكلة. نحتاج إلى تجربة بعض الأمور للتأكد، لكن لدي شعور إيجابي

azawawi · 6 أكتوبر 2019، 9:21ص

يبدو أننا بحاجة إلى تمكينه أولاً وفقًا لتوثيقه. جربته في بيئة التطوير ولم يتم إعادة تحميل أي تغييرات في الإضافات

fzngagan · 6 أكتوبر 2019، 9:23ص

هذا سيكون رائعًا. لقد كان لدي بعض الأمل، لكن كلماتك تمنحني أملًا أكبر. مطورو الإضافات سيعشقون هذا.

الموضوع		الردود	مرات العرض
Upgrading Discourse to Zeitwerk Development dev-news	14	3392	2 أكتوبر 2019
Sidekiq not working Self-hosting	10	1184	2 أكتوبر 2023
"Ensure sidekiq is running." when it is definitely running Self-hosting	19	7868	24 أكتوبر 2015
Development environment : running sidekiq and discourse at startup Development	14	5597	30 أكتوبر 2018
Sidekiq not running. Sidekiq heartbeat test failed, restarting Self-hosting unsupported-install	15	2898	10 يونيو 2020

الإضافات التابعة لجهات خارجية المعطلة

الموضوعات ذات الصلة