Docker 開発環境で Zeitwerk を使用した後の Sidekiq の起動失敗

averi · 2019 年 10 月 2 日午前 10:44

最近、2.4.0.beta4 から 2.4.0.beta5 にアップグレードしたところ、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 · 2019 年 10 月 2 日午後 12:14

これは公式ガイドに従ったインストールではないため、私たちにできることはほとんどありません。

averi · 2019 年 10 月 2 日午後 12:27

現在、Openshift 上で Discourse を運用していますので、当然ながら標準インストールではありません。公式ガイドを確認し、現在のデプロイで何か見落としていないか確認します。ありがとうございます。

azawawi · 2019 年 10 月 2 日午後 12:39

実際、以下の docker コマンドも、VirtualBox 上の私の Discourse Vagrant マシンで同じスタックトレースをトリガーしています:

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

Falco · 2019 年 10 月 2 日午後 12:42

本当にそうでしょうか？公式ガイドには、Sidekiqの手動起動に関する記載も、/home/discourse フォルダの記述もありません。

本番環境で開発用インストールを実行しているんですか？

azawawi · 2019 年 10 月 2 日午後 12:45

Discourseプラグインのテストと開発にDockerコマンドを使用しています。

現在使用している他のスクリプトは以下の通りです：

# Discourseの一時キャッシュをクリアし、開発用Railsを起動
vagrant ssh -c '(rm -rf ~/discourse/tmp/cache)'
vagrant ssh -c '(cd ~/discourse && sudo bin/docker/rails s)'

azawawi · 2019 年 10 月 2 日午後 12:47

もちろん違います

azawawi · 2019 年 10 月 2 日午後 12:50

@Falco これはおそらく以下のコミットに関連していると思います。

どう思いますか？

Falco · 2019 年 10 月 2 日午後 12:51

そうかもしれませんね。これが開発環境ではなく、あなたの開発セットアップであることを明記しなかったことが問題を複雑にしました。

つまり、現在の Docker 開発セットアップが壊れているとおっしゃるのですか？

azawawi · 2019 年 10 月 2 日午後 12:52

はい、そのようです。

azawawi · 2019 年 10 月 2 日午後 12:59

そのコミットを元に戻せば、Sidekiq が再び動作するようになります。

Falco · 2019 年 10 月 2 日午後 1:11

@kris.kotlarek さん、これはあなた向けですね！

kris.kotlarek · 2019 年 10 月 2 日午後 11:32

はい、ここで何が起こったか分かります。私のミスです。Zeitwerk の自動ローダーを使用しているため、多くの require_dependency が不要になったので削除しました。

しかし、application.rb には以下のような記述があります。

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

つまり、Sidekiq は依存関係を見つけるために lib ディレクトリを検索しておらず、特定のファイルで明示的に必要なものを定義しています。

Sidekiq で使用されるファイルに対して require_dependency を復活させるか、application.rb のガード条件を削除するか、どちらかを選ぶことができます。

おそらく、ワーカーのメモリ使用量を節約するために明示的な require を使用していたのでしょう。その方針に従うのが適切だと考えます。require_dependency を復活させます。

@sam どのようにお考えですか？

sam · 2019 年 10 月 2 日午後 11:36

ガードは削除すべきです。プロセスが Sidekiq になるかどうかは分からないからです。当社のデプロイでは、unicorn master → フォーク → sidekiq worker という構成をとっています。フォークの時点で application.rb は既にパースされています。

azawawi · 2019 年 10 月 3 日午前 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 · 2019 年 10 月 3 日午後 11:07

おっしゃる通り、Jobs::Onceoff、Jobs::Base、Jobs::Scheduled はいずれも現在 :: を必要とします。

discourse-whos-online を修正し、他のプラグイン向けにプルリクエストを作成しました：

azawawi · 2019 年 10 月 4 日午前 5:13

@kris.kotlarek ありがとうございます。Zeitwerk オートローダーに関するあなたの投稿を確認しました。プラグイン開発を加速させるために、開発用プラグインの自動リロード機能を有効にする予定はありますか？

kris.kotlarek · 2019 年 10 月 4 日午前 5:33

require や require_dependency が含まれる箇所はまだ残っていますが、多くは削除されました。

これでプラグインのコードが自動的に再読み込みされるはずだと考えています。確認のために少し試してみますが、ポジティブな感触があります

azawawi · 2019 年 10 月 6 日午前 9:21

ドキュメントによると、まずそれを有効にする必要があるようです。開発環境で試してみましたが、プラグインの変更は再読み込みされませんでした

fzngagan · 2019 年 10 月 6 日午前 9:23

それは素晴らしいですね。以前から少し期待はしていましたが、あなたの言葉でさらに希望が湧いてきました。プラグイン開発者の方々はきっと喜ばれるでしょう。

トピック		返信	表示
Upgrading Discourse to Zeitwerk Development dev-news	14	3392	2019 年 10 月 2 日
Sidekiq not working Self-hosting	10	1184	2023 年 10 月 2 日
"Ensure sidekiq is running." when it is definitely running Self-hosting	19	7868	2015 年 10 月 24 日
Development environment : running sidekiq and discourse at startup Development	14	5597	2018 年 10 月 30 日
Sidekiq not running. Sidekiq heartbeat test failed, restarting Self-hosting unsupported-install	15	2898	2020 年 6 月 10 日

動作しないサードパーティ製プラグイン

関連トピック