Sidekiq startet nach Zeitwerk auf Docker Dev nicht

averi · 2. Oktober 2019 um 10:44

Wir haben kürzlich von 2.4.0.beta4 auf 2.4.0.beta5 aktualisiert, und Sidekiq startet nicht mehr. Hier ist der Stacktrace:

> $ 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>'

Habt ihr einen Tipp, wo ich als Nächstes suchen sollte? Danke!

Falco · 2. Oktober 2019 um 12:14

Dies ist keine Installation, die unserem offiziellen Leitfaden gefolgt ist, daher können wir Ihnen nicht viel helfen.

averi · 2. Oktober 2019 um 12:27

Wir betreiben derzeit Discourse auf OpenShift, also handelt es sich sicher nicht um eine Standardinstallation. Ich werde den offiziellen Leitfaden prüfen und sehen, ob ich bei der aktuellen Bereitstellung etwas übersehen habe. Danke.

azawawi · 2. Oktober 2019 um 12:39

Tatsächlich löst sogar der folgende Docker-Befehl denselben Stack-Trace in meiner Discourse-Vagrant-Maschine über VirtualBox aus:

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

Falco · 2. Oktober 2019 um 12:42

Bist du dir da sicher? Der offizielle Leitfaden enthält nichts zu manuellen Starts von Sidekiq, und es gibt auch keinen Ordner /home/discourse darin.

Führst du eine Entwicklungsinstallation in der Produktion aus?

azawawi · 2. Oktober 2019 um 12:45

Ich verwende Docker-Befehle, um Discourse-Plugins zu testen und zu entwickeln.

Das andere Skript, das ich derzeit verwende, lautet:

# Temporären Discourse-Cache leeren und Entwicklungsrails starten
vagrant ssh -c '(rm -rf ~/discourse/tmp/cache)'
vagrant ssh -c '(cd ~/discourse && sudo bin/docker/rails s)'

azawawi · 2. Oktober 2019 um 12:47

Natürlich nicht

azawawi · 2. Oktober 2019 um 12:50

@Falco Ich denke, das hängt damit zusammen:

Was meinst du dazu?

Falco · 2. Oktober 2019 um 12:51

Das kann sein. Dass Sie nicht erwähnt haben, dass dies Ihre Entwicklungsumgebung und keine Dev-Umgebung ist, hat nicht gerade geholfen.

Sagen Sie also, dass unser Docker-Dev-Setup derzeit defekt ist?

azawawi · 2. Oktober 2019 um 12:52

Ja, das sieht so aus.

azawawi · 2. Oktober 2019 um 12:59

Durch das Zurücknehmen dieses Commits funktioniert Sidekiq wieder.

Falco · 2. Oktober 2019 um 13:11

Sieht aus, als wäre das eine Sache für dich, @kris.kotlarek

kris.kotlarek · 2. Oktober 2019 um 23:32

Ok, ich weiß, was hier passiert ist, das liegt an mir. Ich habe viele require_dependency-Aufrufe entfernt, da sie bei Verwendung des Zeitwerk-Autoloaders nicht mehr erforderlich sind.

Allerdings haben wir in application.rb Folgendes:

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

Das bedeutet, dass Sidekiq nicht im lib-Verzeichnis nach Abhängigkeiten sucht und wir explizit definieren, was in bestimmten Dateien benötigt wird.

Ich könnte das require_dependency für Dateien, die von Sidekiq verwendet werden, wiederherstellen oder die Bedingung in application.rb entfernen.

Ich vermute, dass wir diese expliziten require-Aufrufe genutzt haben, um Arbeitsspeicher für Worker zu sparen, also sollten wir wahrscheinlich diesen Weg weiterverfolgen. Ich werde require_dependency wiederherstellen.

@sam, was ist deine Meinung?

sam · 2. Oktober 2019 um 23:36

Wir sollten die Bedingung entfernen. Mir gefällt sie nicht, da man nicht weiß, ob der Prozess zu einem Sidekiq wird oder nicht. Bei unseren Bereitstellungen haben wir: Unicorn Master → Fork → Sidekiq Worker. Zum Zeitpunkt des Forks wurde application.rb bereits geparst.

azawawi · 3. Oktober 2019 um 07:18

@kris.kotlarek Danke für die Korrektur. Sidekiq funktioniert jetzt zusammen mit den offiziellen Discourse-Plugins .

Die meisten meiner Plugins von Drittanbietern mit Jobs funktionieren derzeit nicht . Höchstwahrscheinlich liegt dies daran, dass der folgende Commit nicht auf ihre Jobs::-Klassen angewendet wurde.

Defekte Plugins von Drittanbietern

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. Oktober 2019 um 23:07

Du hast recht, alle Jobs::Onceoff, Jobs::Base und Jobs::Scheduled benötigen jetzt ::

Ich habe discourse-whos-online repariert und Pull Requests für andere Plugins erstellt:

azawawi · 4. Oktober 2019 um 05:13

@kris.kotlarek Vielen Dank . Ich habe mir deinen Beitrag zum Zeitwerk-Autoloader angesehen. Gibt es einen Plan, eine Funktion zum automatischen Neuladen von Entwicklungs-Plugins zu aktivieren, um die Plugin-Entwicklung zu beschleunigen?

kris.kotlarek · 4. Oktober 2019 um 05:33

Es gibt noch Stellen, die require oder require_dependency enthalten, aber viele wurden entfernt.

Ich denke, dass der Code des Plugins jetzt automatisch neu geladen werden sollte, ohne Probleme. Wir müssen ein wenig testen, um sicherzugehen, aber ich habe ein gutes Gefühl

azawawi · 6. Oktober 2019 um 09:21

Es scheint, dass wir es zunächst gemäß der Dokumentation aktivieren müssen. Ich habe es in der Entwicklung ausprobiert, aber keine Plugin-Änderungen wurden neu geladen

fzngagan · 6. Oktober 2019 um 09:23

Das wäre großartig. Ich hatte schon etwas Hoffnung, aber deine Worte geben mir noch mehr. Plugin-Entwickler werden das lieben.

Thema		Antworten	Aufrufe
Upgrading Discourse to Zeitwerk Development dev-news	14	3401	2. Oktober 2019
Sidekiq not working Self-hosting	10	1188	2. Oktober 2023
"Ensure sidekiq is running." when it is definitely running Self-hosting	19	7874	24. Oktober 2015
Development environment : running sidekiq and discourse at startup Development	14	5604	30. Oktober 2018
Sidekiq not running. Sidekiq heartbeat test failed, restarting Self-hosting unsupported-install	15	2898	10. Juni 2020

Defekte Plugins von Drittanbietern

Verwandte Themen