はじめに
前回の記事では、Redmine 6.xへの移行準備として、redmine_dmsf を完全に切除しました。
その流れで、「それならKnowledgebaseも同じ手順で片付くだろう」と考えたのが、今回の始まりです。
長年ナレッジ管理として活躍してくれた redmine_knowledgebase ですが、現在はMarkdownネイティブな BookStack を主に利用しており、今後も利用予定はありません。
Redmine 6.xへのメジャーバージョンアップを見据え、依存関係を少しでも整理するため、完全アンインストールを行うことにしました。
前回の教訓もあります。
「マイグレーションを一つずつ戻す」のではなく、
- データベース
- マイグレーション履歴
- プラグイン本体
をまとめて切除する外科手術方式です。
ところが今回は、それだけでは終わりませんでした。
Knowledgebaseを削除したはずなのに、ブラウザには何度アクセスしても
We're sorry, but something went wrong.
と表示され続けます。
今回の記事は、この500エラーの犯人を追い掛けた記録です。
今回の前提
今回の作業も、本番環境ではなく前回構築した Side-by-Side 構成の検証環境 (redmine-clone) で実施しています。
| 項目 | 内容 |
|---|---|
| 対象環境 | 検証環境（redmine-clone） |
| Redmine | 5.1系 |
| Ruby | 3.2系 |
| Rails | 6.1 |
| Database | MySQL 8.x |
| 対象プラグイン | redmine_knowledgebase |
今回も、「失敗してもやり直せること」を前提に作業を進めています。
まずはバックアップ
前回と同様、テーブル削除を伴うため、最初にMySQLのダンプを取得します。
mysqldump \
--single-transaction \
--routines \
--triggers \
--default-character-set=utf8mb4 \
-u redmine_clone \
-p \
redmine_clone \
> redmine_clone_before_knowledgebase.sqlこのバックアップが、最後の保険です。
Step1 Knowledgebaseを切除する
今回は最初から外科手術方式を採用しました。
まずは関連テーブルを削除します。
USE redmine_clone;
SET FOREIGN_KEY_CHECKS = 0;
DROP TABLE IF EXISTS
kb_articles,
kb_article_versions,
kb_categories;
SET FOREIGN_KEY_CHECKS = 1;続いて、マイグレーション履歴を削除します。
DELETE
FROM schema_migrations
WHERE version LIKE '%-redmine_knowledgebase%';注意
この方法は「Knowledgebaseを今後利用しない」ことを前提としています。
将来的に再利用する予定がある場合は、通常の移行手順を検討してください。
最後にプラグイン本体を退避します。
cd /home/www-data/redmine-clone
sudo mv plugins/redmine_knowledgebase \
/home/www-data/retired_plugins/
sudo touch tmp/restart.txtここまでは、前回のDMSFとほぼ同じ流れです。
そして私は、この時点で終わったと思っていました。
……終わらなかった
ブラウザを更新すると、
We're sorry, but something went wrong.
The issue has been logged for investigation.
Please try again later.何度更新しても500エラー。
Knowledgebaseは削除したはずです。
それなのにRedmineは起動しません。
ここから、本当の原因調査が始まりました。
容疑者その1 ― ログが出ていない
まず最初にproduction.logを確認します。
……ところが、ログが増えません。おかしい。
シンボリックリンクを確認すると、
/home/www-data/redmine-clone/log
↓
/var/log/redmineなんと、検証環境のログが本番環境を向いたままでした。
クローン作成時に張り替えたつもりだったシンボリックリンクが、そのまま残っていたのです。
修正します。
cd /home/www-data/redmine-clone
sudo rm log
sudo ln -sf /var/log/redmine-clone logこれでようやく検証環境のログが取得できるようになりました。
……しかし、500エラーは変わりません。容疑者その1、シロでした。
容疑者その2 ― Passenger
次に、Passengerを完全再起動します。
そこで、
passenger-config restart-appを実行すると、
ArgumentError:
too long unix socket path
(116 bytes given but 108 bytes max)というエラー。
UNIXドメインソケットの108バイト制限に引っ掛かっていました。
結局、
sudo touch tmp/restart.txt
sudo systemctl reload apache2という昔ながらの方法で再起動することにしました。
……それでも500エラー。Passengerも違いました。
真犯人
ログが正常に取得できるようになったため、
rake コマンドで環境初期化を実行すると、ついに原因が現れました。
NoMethodError:
undefined method
`requires_redmineup'
plugins/redmine_questions/init.rbKnowledgebaseではありませんでした。
真犯人は redmine_questions です。
Redmineは起動時に、すべてのプラグインの init.rb を読み込みます。
Knowledgebaseを削除しても、同居していた redmine_questions が redmineup のメソッドを要求し、その時点で初期化が停止していました。
つまり、Knowledgebaseを削除したことで壊れたのではなく、
以前から潜んでいた依存関係の問題が表面化しただけだったのです。
決断 ― 疑わしき依存はすべて切り離す
redmine_questions の利用状況を改めて確認した結果、今後利用する予定はありませんでした。依存関係を抱えたままRedmine 6.xへ進むリスクを考え、こちらもKnowledgebaseと同様に完全切除することにしました。
Questionsを切除する
まずは関連テーブルを削除します。
mysql -u redmine_clone -pUSE redmine_clone;
SET FOREIGN_KEY_CHECKS = 0;
DROP TABLE IF EXISTS
questions,
questions_answers,
questions_sections,
questions_statuses;
SET FOREIGN_KEY_CHECKS = 1;続いてマイグレーション履歴を削除します。
DELETE
FROM schema_migrations
WHERE version LIKE '%-redmine_questions%';最後にプラグイン本体を退避し、キャッシュを削除します。
sudo mv \
plugins/redmine_questions \
/home/www-data/retired_plugins/
sudo rm -rf tmp/cache/*
sudo touch tmp/restart.txt
sudo systemctl reload apache2動作確認
ブラウザを更新すると……
500エラーは完全に解消しました。確認できた内容は次のとおりです。
- Redmineが正常起動する
- トップページが表示される
- 管理画面へログインできる
- Plugin一覧から
- DMSF
- Knowledgebase
- Questions
が消えている
- エラーログに新たな例外が出ていない
ここまで確認できれば、今回の切除作業は完了です。
おわりに
今回の500エラーは、Knowledgebaseそのものが原因ではありませんでした。
長年運用してきたプラグイン同士の依存関係が、Knowledgebaseの切除をきっかけに姿を現しただけだったのです。
一つ外せば終わると思っていたものが、実際には別のプラグインを炙り出す。長期間運用してきたRedmineらしい現象だったと感じています。
結果として、
redmine_dmsfredmine_knowledgebaseredmine_questions
という、今後利用予定のない大型プラグインを整理することができました。
Redmine本体はまだ5.1のままですが、不要な依存を抱えない、できるだけ素の状態へ近づけることができています。
そして今回も、問題の切り分けが落ち着いてできたのは、前回構築した redmine-clone の存在があったからです。
本番環境だったら、500エラーが出るたびに焦っていたかもしれません。しかし検証環境だからこそ、一つずつ仮説を立て、ログを確認し、原因を潰していくことができました。
いよいよ次は、Redmine 6.xへのメジャーバージョンアップの下準備です。
ここまで整理してきた環境が、どこまで素直に新しいバージョンを受け入れてくれるのか。それを確認する段階まで、ようやくたどり着きました。
