Sidekiqの定期ジョブにmedia_cleanup_schedulerってあるから自動でtootctl media removeを行ってくれるのかと思ったけどそういうものではない?

ログをみたところインターバルが0 * * * *のinstance_refresh_schedulerと5mのscheduled_statuses_schedulerとtrending_tags_schedulerは動いている。それ以外は動いていない。
media_cleanup_schedulerすぐにエンキューを押すと動いてcache/media_attachmentsからファイルが消える。範囲不明で数は少ない。連続で押しても2回目は何も消えないのでそれなりに判定はしていそう。
Sidekiqのスケジュールはパラメーターが6個という情報も。
Ruby - sidekiq.yml の定期実行の書き方について|teratail
teratail.com/questions/163097

フォロー

@bmwandmore tootctl media removeは任意のもので、やらない方針をとることもあるので、勝手に実行したりはしません。

投稿に先立ってアップロードしたファイルのうち、投稿に使用しなかったものなど、どこにも添付されていないMediaAttachmentを掃除するタスクです。

なるほど。そうするとtootctl media removeは実行するようにしないとダメかな。ありがとうございます。

sidekiqのパラメーター指定、やはり6個必要なようです。1つ追加したジョブは自動実行されました。

@bmwandmore schedulerのパラメータ解析は、最終的にfugit.parseがになっていて、5パラメータでちゃんと動くように読めます。
github.com/floraison/fugit#fug

そして、実際ウチのschedulerログではそれぞれ定期実行されてますね。

sudo journalctl -ru mastodon-sidekiq-scheduler -g MediaCleanupScheduler

なるほど。普通は動くんですね。こちらもとりあえずは動いたからまあいいかな、と。
ruby2.7.2環境にfugitがいないとかいう問題かな?

@bmwandmore fugitいなかったら、schedulerの設定読み込みの時点でエラーになって、Mastodonが立ち上がらないと思います。依存の中で使われるのでGemfileには記述されませんが、Gemfile.lockの中に確認できるかと思います。

ruby 2.7.2ということであれば、2.7.0ディレクトリのfugit-1.3.9を使っているのではないでしょうか。たぶんディレクトリはメジャーバージョン毎です。

>ディレクトリはメジャーバージョン毎
そうなんですね。たしかに2.6.0も2.7.0も入れた記憶ないですし。
fugitは1.3.9がGemfile.lockにいるのでこれが使われているようです。
そうなると何で5個で動かないの?と言う部分と誤って直接gem installしてfindでは見つかるけどgemコマンドでは見つからない1.4.2の処分をどうしようかな、と。まあ、見えないんで問題は起こさないと思いますが。

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。