Sidekiq non si avvia dopo l'attivazione di Zeitwerk in docker dev

averi · 2 Ottobre 2019, 10:44am

Di recente abbiamo aggiornato da 2.4.0.beta4 a 2.4.0.beta5 e Sidekiq non riesce ad avviarsi con il seguente traceback:

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

Avete qualche indicazione su dove guardare oltre? Grazie!

Falco · 2 Ottobre 2019, 12:14pm

Questa non è un’installazione seguita dalla nostra guida ufficiale, quindi non possiamo offrirvi molto aiuto.

averi · 2 Ottobre 2019, 12:27pm

Al momento stiamo eseguendo Discourse su OpenShift, quindi sicuramente non si tratta di un’installazione standard. Rivedrò la guida ufficiale per verificare se ho tralasciato qualcosa nella distribuzione attuale, grazie.

azawawi · 2 Ottobre 2019, 12:39pm

In realtà, anche il seguente comando Docker innesca la stessa traccia dello stack nella mia macchina Vagrant di Discourse su VirtualBox:

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

Falco · 2 Ottobre 2019, 12:42pm

Ne sei sicuro? La guida ufficiale non menziona avvio manuale di sidekiq e non c’è alcuna cartella /home/discourse.

Stai eseguendo un’installazione di sviluppo in produzione ??

azawawi · 2 Ottobre 2019, 12:45pm

Sto usando i comandi Docker per testare e sviluppare plugin di Discourse.

L’altro script che sto attualmente utilizzando è:

# Pulire la cache temporanea di Discourse e avviare Rails in modalità sviluppo
vagrant ssh -c '(rm -rf ~/discourse/tmp/cache)'
vagrant ssh -c '(cd ~/discourse && sudo bin/docker/rails s)'

azawawi · 2 Ottobre 2019, 12:47pm

Certo che no

azawawi · 2 Ottobre 2019, 12:50pm

@Falco Penso che sia correlato a

Cosa ne pensi?

Falco · 2 Ottobre 2019, 12:51pm

Forse sì. Il fatto che tu non abbia specificato che si tratta del tuo setup di sviluppo e non di un ambiente di sviluppo non ha aiutato.

Quindi stai dicendo che il nostro setup di sviluppo Docker è attualmente rotto?

azawawi · 2 Ottobre 2019, 12:52pm

Sì, sembra proprio così.

azawawi · 2 Ottobre 2019, 12:59pm

Ripristinare quell’commit fa funzionare di nuovo Sidekiq.

Falco · 2 Ottobre 2019, 1:11pm

Sembra che questa sia una cosa per te @kris.kotlarek

kris.kotlarek · 2 Ottobre 2019, 11:32pm

Ok, so ora capisco cosa è successo, è colpa mia. Ho rimosso molti require_dependency poiché non sono più necessari quando si utilizza l’autoloader di Zeitwerk.

Tuttavia, in application.rb abbiamo questo:

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

Ciò significa che Sidekiq non cerca nella directory lib per trovare le dipendenze e definiamo esplicitamente cosa è richiesto nei file specifici.

Potrei ripristinare quel require_dependency per i file utilizzati da Sidekiq oppure rimuovere quella condizione in application.rb.

Penso che abbiamo usato quel require esplicito per risparmiare memoria sui worker, quindi probabilmente dovremmo seguire questa strada. Ripristinerò require_dependency.

@sam, qual è il tuo parere?

sam · 2 Ottobre 2019, 11:36pm

Dovremmo rimuovere la guardia; non mi piace perché non hai modo di sapere se il tuo processo diventerà o meno un Sidekiq. Nelle nostre distribuzioni abbiamo: unicorn master → fork → sidekiq worker. Al momento del fork, application.rb era già stato analizzato.

azawawi · 3 Ottobre 2019, 7:18am

@kris.kotlarek Grazie per la correzione. Sidekiq ora funziona insieme ai plugin ufficiali di Discourse .

La maggior parte dei miei plugin di terze parti con job non funziona più . Molto probabilmente causato dal seguente commit non applicato alle loro classi Jobs::.

Plugin di terze parti non funzionanti

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 Ottobre 2019, 11:07pm

Hai ragione, ora tutti Jobs::Onceoff, Jobs::Base e Jobs::Scheduled richiedono ::

Ho corretto discourse-whos-online e creato pull request per altri plugin:

azawawi · 4 Ottobre 2019, 5:13am

@kris.kotrarek Grazie mille . Ho dato un’occhiata al tuo post sull’autoloader di Zeitwerk. C’è l’intenzione di attivare una funzionalità di auto-ricarica per i plugin in fase di sviluppo per velocizzare lo sviluppo dei plugin?

kris.kotlarek · 4 Ottobre 2019, 5:33am

Ci sono ancora alcuni punti che contengono require o require_dependency, ma molti sono stati rimossi.

Penso che ora il codice del plugin dovrebbe essere ricaricato automaticamente senza problemi. Dobbiamo fare qualche prova per esserne certi, ma ho un buon presentimento

azawawi · 6 Ottobre 2019, 9:21am

Sembra che dobbiamo prima attivarlo, come indicato nella sua documentazione. L’ho provato in ambiente di sviluppo, ma non sono stati ricaricati cambiamenti ai plugin

fzngagan · 6 Ottobre 2019, 9:23am

Sarebbe fantastico. Avevo già un po’ di speranza, ma le tue parole mi danno ancora più speranza. Gli sviluppatori di plugin adoreranno questa cosa.

Argomento		Risposte	Visualizzazioni
Upgrading Discourse to Zeitwerk Development dev-news	14	3386	Ottobre 2, 2019
Sidekiq not working Self-hosting	10	1180	Ottobre 2, 2023
"Ensure sidekiq is running." when it is definitely running Self-hosting	19	7859	Ottobre 24, 2015
Development environment : running sidekiq and discourse at startup Development	14	5580	Ottobre 30, 2018
Sidekiq not running. Sidekiq heartbeat test failed, restarting Self-hosting unsupported-install	15	2890	Giugno 10, 2020

Plugin di terze parti non funzionanti

Argomenti correlati