素人がMastodonインスタンス運用でハマったトラブルシューティング10選+α v1.2.2 → 中略 → v3.1.0rc2
2017年の4月22日に、なんとなくMastodonの可能性に魅力を感じ、そのままの勢いで「十日町市のMastodon」というインスタンスを立ち上げました。
それから数日後に書いた記事がこちら。
あと、こんな記事も書きました。
そして、立ち上げからちょうど1か月が経ちました。
なにぶん初心者というか素人が勢いで立ち上げたものですから、とにかく基本的な知識を学びながらの手探りです。セミリタイアの隠居生活なのでいつも夜11時に寝ていたところを、問題解決のために徹夜したこともありました。
結果的には、この1か月間たいへんだったけど、とても楽しかったです。
というわけで、そんな自分がハマったことを書き留めておこうと思います。
この記事がもし、ほかの誰かの参考にもなったら、なおうれしいです。
1. サーバーのメモリは多めに
じぶんはインスタンス用のサーバーとして、「さくらのクラウド」というホスティングサービスのものを利用しています。
サーバーOSは《CentOS7》です。
サーバーの基本性能は《1core・4GB》となっています。
Mastodonでは最新バージョンのデータを反映させるときなどに
$ RAILS_ENV=production bundle exec rails assets:precompile
というコマンドを使いますけど、この処理がメモリを大量に消費するらしく？しかも初心者だし何が起きるかわからず不安だから1GBではなく念のため4GBと多めにしました。
「さくらのクラウド」ではMastodonのスタートアップスクリプトというものが提供されていて、初心者でも比較的簡単にインスタンスを立ち上げることができるようになっていると思います。
2. gitの使い方がわからない
Mastodonをそもそも開発した本家のデータは、GitHubというサイトに保管されていて、インスタンスを立ち上げるにはそこから最新のデータをじぶんのサーバーにダウンロードしなければなりません。
そのときに使うのが、git というコマンドです。
たとえばこんなコマンドがあります。
$ git clone URL
$ git fetch
$ git checkout (git tag | tail -n 1)
こうしたダウンロードの方法を初めてネットで見たときの印象は
「なにこれ、実際どうやるの？」
という感じでした。
これらに関しては、初心者向けの入門記事がいろいろありますので、ひとつずつ勉強していきました。
ただ、やっぱり基礎知識がなかったため、いろいろ間違えたみたいで、じぶんのインスタンスがエラーを発して動かなくなったことが何回もありました。
最終的に落ちついたのは、下記3の方法でした。
3. バージョンアップの方法がわからない
Mastodonの本家のデータはものすごい勢いでどんどんアップデートされています。そして、数日ごとの節目にバージョンアップの対象となる本格的なリリースが行われます。
なので、毎日このページをチェックしています。
この記事を書いているときの最新バージョンはv1.4rc2（v1.4.0.2）。それでも安定したバージョンでなかったりすることもあります。しかも、たとえおかしくなってもすべて自己責任。
ひとつずつ経験値をためながらの1か月でした。
まず言えることは、本家の公式ドキュメントやUpdate noteをしっかり読もうというところでしょうか。基本的なことなんでしょうけど、改めてそう思いました。いまではGoogle翻訳を使いながらよく読むようにしています。
そうしてこなかったせいと、さまざまな基礎知識が不十分だったので、じぶんのサーバーと本家とでデータの食い違いが発生したり、へたにデータをいじってしまったりで、たいへんな目に逢いました。
けっきょく最後のほうでは
$ git reset --hard origin/master
というコマンドで強制リセット。
いまでは
$ git pull
を使うと《あなたは最新の状態ですよ》という意味のメッセージが出るようになって落ちつきました。
4. ユーザー数とトゥート数が更新されない!?
そのとき問題となったのは、この「サーバー情報」です。
試行錯誤してバージョンアップしてきたせいで、ユーザー数とトゥート数がまったく変わらず、増えなかったときがありました。
じぶんがトゥートしたにもかかわらずトゥート数が増えないんです。
いろいろ調べた結果、このコマンドを実行したら直りました。
$ RAILS_ENV=production bundle exec rails runner 'Rails.cache.clear'
直ったときのうれしさと言ったら ... 格別でした。
5. something went wrong が出ちゃった
冒頭の写真がそれですね。これが出てしまうとMastodonそのものがまったく利用できなくなります。
500 error とも Internal Server Error とも呼ばれる現象らしいです。
これが出るようだと、数日インスタンスが稼働せず、悶々とした日々を過ごす羽目になりました。
そんなとき、このコマンドで直りました。
$ RAILS_ENV=production bundle exec rails webpacker:compile
something went wrongのイラストはかわいいけど、できればもう見たくないです...。
6. エラーログを見よう!!
もっと早くログのことを知っていれば、どこがエラーになっているのか、その原因の特定がしやすかったでしょう。
これも基本的なことなんでしょうけど。
エラーログを見るにはサーバー内にある
/var/log/nginx/error.log
というファイルをテキストエディタで開いて確認したり
# journalctl -xf -u mastodon-*
エラーがわかったら Ctrl + C で実行中止
というコマンドを使いました。
これによってエラーの原因がわかり、それをもとにネット検索することで解決方法が見つかることがよくありました。
7. CLD3のコンパイルエラー
という表現でいいのでしょうか。Mastodonがたしかv1.3.2になったとき？だったと思うのですが、言語フィルターという新機能が実装された際、このCLD3という新しいプログラムが追加されました。
このときも、じぶんの知識が不十分で、めちゃくちゃな方法でアップデートしたため、CLD3をうまくインストールできていなかったんです。
いまでもよく理解していないんですけど、エラーにはextconf.rbというファイルも関係していたようでした。
そこで実行したコマンドが、これ。
$ yum install protobuf-compiler libprotobuf-dev
$ yum install protobuf-devel boost-devel gflags-devel lmdb-devel
8. git pullできない!?
これは3にも関係しています。バージョンアップ時のエラーです。
そんなときは
$ sudo chown -R mastodon .git/
を実行して解決しました。
9. ほかにも実行したコマンド
・Mastodonのバージョンアップ時、precompileでエラーが出たら、いちどassetsディレクトリをリセット。
$ RAILS_ENV=production bundle exec rails assets:clobber
・それでもprecompileでエラーが出たとき。
config/environments/production.rbのconfig.assets.compile
の値をfalseからtrueに変更
・挙動がおかしいのを個別にインストール。
$ gem install cld3 -v '3.1.1'
上記7のCLD3ならばこんな感じ
・なにか変更したらMastodonを再起動。
$ RAILS_ENV=production bundle exec rails db:migrate
$ RAILS_ENV=production bundle exec rails assets:precompile
$ exit
をしてからだったり、省いたりしてから
# systemctl restart mastodon*
・じぶんのサーバーが本家と同じ最新の状態かを確認するとき。
$ git remote show origin
実行後、最終行にlocal out of dateと出たら古いとわかる
個別に確認するときは各プログラム名の末尾に「-v」を付ける
$ rails -v
・コマンド実行結果が画面の上に流れて見えなくなるのを止めるとき。
$ git pull | more
コマンドの末尾に縦棒の「|」と「more」を付ける
中止するときは「:」キーを押してから「q」を押す
むしろ「q」だけで止まる!?
10. 調べるときに重宝したサイト
・qiita
https://qiita.com/
たとえばバージョンを戻す方法もあるらしいです。
・マストドン横断検索
http://mastodonsearch.jp/cross/
インスタンス管理者のみなさんのつぶやきはヒントが多いです。
以上、まとめでした。
実際にはもっといろんなことがあって。
解決したときは思わず「やったあ！動いたあ!!」と感動するわけですが、原因がわかればあっけないものばかり。これを仕事にしているひとたちはすごいとしか言いようがないです。
素人によるMastodonのインスタンス運用は、これからもいろいろあるでしょうけど、楽しんでいきたいと思います。
以下、その後の追記です
・2017年7月15日
なんとITmedia『マストドンつまみ食い日記』に取り上げられました。ご当地インスタンス専用アプリの走りだったそうです。
地域丼もモバイルアプリ? 十日町に続き大阪も
http://www.itmedia.co.jp/news/articles/1707/15/news038.html
・2017年7月25日
v1.4.7からv1.5.0rc1にバージョンアップしたときにつまずいたところを以下に追記しました。
bundle installのときに、下記の3つのパッケージをインストールできずにエラーが出ました。
case_transform
charlock_holmes
idn-ruby
なので、下記のコマンドをひとつずつ実行したらインストールできました。
まずcase_transformについては
$ gem install case_transform -v '0.2'
を実行して個別にインストールしました。
続いてcharlock_holmesについては
$ yum install libicu-devel
を実行したあとに
$ gem install charlock_holmes -v '0.7.3'
というコマンドでインストールできました。
と、ここまでは順調にクリアしてきたのですが、3つめのidn-rubyがたいへんでした。
本家のリリースノートに「New system package dependency: libidn11-dev」とあるように、libidn11-devというパッケージのインストールがあらかじめ必要とのこと。
そのため、いろいろ調べてようやくわかったのが
# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/libidn-devel-1.28-4.el7.x86_64.rpm
# rpm -ivh libidn-devel-1.28-4.el7.x86_64.rpm
を実行するということ。つまり、libidn-devel-1.28-4.el7.x86_64.rpmをダウンロード＆インストールしました。
ちなみに、wgetというコマンドは
# yum list | grep wget
# yum install wget
と実行することで使えるようになりました。
そのうえで
$ gem install idn-ruby -v '0.1.0'
としたら、今回のv1.5.0rc1に必要なパッケージがすべて揃いました。
あとはいつもどおり本家のリリースノートに従っていくことで、v1.5.0rc1にバージョンアップ完了！
おつかれさまでした。
・2017年8月9日
v1.5.0rc1からv1.5.1にバージョンアップしたときにつまずいたところを以下に追記しました。
一瞬バージョンアップできたと思ったら、新機能のWeb share buttonが反映されていないなあと気づいて、下記のコマンドを実行したんです。
$ RAILS_ENV=production bundle exec rails webpacker:compile
そうしたら、something went wrongのイラストが出てしまい、数日のあいだインスタンスが使えない状態になってしまいました。
いろいろ調べた結果、下記のコマンドであっさり解決しました。
$ NODE_ENV=production ./bin/webpack
もうsomething went wrongのイラストを見たくなかったのですが、解決してホッとしました。
・2017年8月11日
v1.5.1にバージョンアップしたときの追記。
「ホーム」のタイムラインが古いままで更新されず、うまく表示されない現象が起こりました。
そこで公式ドキュメントを参考にしながら
$ RAILS_ENV=production bundle exec rake mastodon:feeds:build
というコマンドでタイムラインを再生成。
これでタイムラインが元に戻りました。
・2017年10月11日
v2.0.0rc1にバージョンアップしたときの追記。
ついにやってきた待望のメジャーアップデート。やはり超えなければならないハードルが立ちふさがっていました。
まずは、Ruby 2.4.2が必要でした。bundle installといった通常のアップデート作業に必要なコマンドを実行しようとしても「2.4.2が必要ですよ」というメッセージが出てしまったんです。
そこで、いろいろ調べてみたら、じぶんのサーバーにはRuby 2.4.1がインストール済みだったので、2.4.2へのアップデートを試みました。
ところが
$ rbenv install -l
というコマンドで表示される「インストール可能なRubyのバージョンのリスト」に2.4.2が出てこなかったんです。
このため、リストを最新の状態に更新する必要がありました。
$ cd ~/.rbenv/plugins/ruby-build
$ git pull origin master
これらのコマンドでリストを更新。
そのうえでMastodonのいつものディレクトリに戻って
$ rbenv install 2.4.2
を実行。これでRuby 2.4.2のインストールが行われました。
そしてその後
$ rbenv rehash
$ rbenv global 2.4.2
というコマンドにより、システム全体で使用するバージョンを指定。
これでRuby 2.4.2のインストールが完了しました。
あとはMastodonの公式リリースノートの手順にしたがってアップデート。毎回恒例のdb:migrateやassets:precompileでは、いつもより時間を要しましたけど、問題なく終わったようです。
が、ここでまた問題発生。Web UIが表示されなくなりました。
そこで、以前にもこのnoteで書きましたけど
$ NODE_ENV=production ./bin/webpack
を実行し、rootに戻って
# systemctl restart mastodon*
によるシステム再起動。
無事、Web UIが表示されてv2.0.0rc1へのアップデート完了です。
おつかれさまでした。
［余談］APIが変わったのでしょうか。じぶんがiPhoneで使っているスマホ用アプリ「Pawoo」で https://tokamstdn.jp/ のタイムラインが表示されなくなりました。アプリの対応待ちでしょうか。それとも!?
・2018年3月1日
502 Bad Gatewayが出てしまったときの話。
v2.2.0にアップデート後、しばらく快調に動作していたのですが、とつじょ「502 Bad Gateway - nginx」というエラー画面が表示され、インスタンスがまったく稼働しなくなりました。
え、何もいじっていないのに!?
どうして勝手に。
まさかサイバー攻撃!?
いろいろ調べたところ、原因はどうやらサーバーのディスク容量が足りなくなったようです。20GBのプランを使っていましたが「え ... もうそんなに使ったかな」と釈然としないまま40GBに拡張すべく下記のとおり対処しました。
まず、こちらのページを参考にしながら「ディスク拡張作業」を実行。
順調に進みましたけど、同ページの「サーバ上で認識されるディスクサイズを拡張する」の部分から難航。
要はパーティションサイズを拡張するという意味らしいのですが
# parted -l
というコマンドを実行してからがうまくいきません。
というのもサーバーにはParted 3.1がインストール済みで、肝心の
# resizepart 3
をパスするにはParted 3.2が必要ということがわかったのです。
そこで、そのParted 3.2をインストールしようとしましたが、どうしてもうまくいきません。
ああ、もうダメだあ...
とあきらめかけたのですが、なんと、そんなことしなくてもパーティションサイズを拡張する方法があったのです。
それが、こちらのページに書かれてありました。
これだ！
さっそくサーバーを停止させてから「パーティションサイズの拡張」を実行。
そうしたら！
復活！！
うれしすぎる。
ほんとうに一時はどうなるかと思いましたが ...。
久しぶりにハマりましたけど、この感動が味わえるからやめられませんね。これからも精進します。おやすみなさい。
（夜11時に問題が発覚して復活したのが深夜3時過ぎでした...）
※あとで知ったんですけど下記のRakeタスクを実行すると7日を経過したメディアファイルのキャッシュを削除できるようです。こっちのほうがすぐ空き容量不足に対応できそうですね。実際にやったら約12GBの空き容量を確保できました。
$ RAILS_ENV=production bundle exec rake mastodon:media:remove_remote
・2018年4月22日
祝1周年。こんなnoteを書きました。
・2018年4月28日
うれしいことに、地元の『妻有新聞』に掲載されました。
・2018年5月19日
「さくらのクラウド」スタートアップスクリプトによるMastodonをv2.3.3からv2.4.0rc3にバージョンアップした時につまずいた話。
PostgreSQLを9.2.18から9.4以上にアップグレードしないといけなかった件。
これがまたたいへんでした...。
というわけで別のnoteにまとめました↓
・2018年8月28日
「さくらのクラウド」スタートアップスクリプトによるMastodonをv2.4.5からv2.5.0rc1にバージョンアップした時につまずいた話。
いつものようにやっていたら「yarn install」で下記のようなメッセージが出ました。
The engine "node" is incompatible with this module ...
いろいろ調べた結果、node.js というJavaScript環境のバージョンが合わないらしいので、現在のバージョンを確認してみました。
$ node -v
v6.11.2
というわけでnode.jsをひとつ上？のv8.xにバージョンアップしてみました。
ところが...。
公式の説明どおりにやってもv6.4.xがインストールされるばかり。v8.xをインストールすることができません。
そこで、こちらの記事を参考にしながらやってみました。
https://qiita.com/robitan/items/a684a81214767c21a560
じぶんの場合の手順は下記のとおり。
$ exit
MastodonディレクトリからいったんROOTに戻り、下記のコマンドを使っていきました
# yum remove nodejs
# rm /etc/yum.repos.d/nodesource-el.repo
# yum clean all
# curl -sL https://rpm.nodesource.com/setup_8.x | bash -
# yum install nodejs
以上でnode.jsのv8.11.4をインストールできました。
そのあと、いつものようにyarn installやdb:migrateなどをしましたが、Mastodonの再起動ができなかったので、サーバー自体の再起動を行ったところ、Mastodon v2.5.0rc1にバージョンアップ完了できました。
以上です。
おつかれさまでした。
・2018年10月21日
Mastodonをv2.5.2からv2.6.0rc1にバージョンアップした時につまずいた話。
公式のドキュメントを読むとRubyの推奨バージョンがv2.5.3になったそうなので、Rubyをv2.5.1からv2.5.3にバージョンアップしようとしました。
ところが上記にも書いた方法で
$ rbenv global 2.5.3
$ ruby -v
としてもv2.5.3に切り替わりません。
そこでいろいろ調べたところ下記のようにしたらRubyがv2.5.3に切り替わりました。
# su - mastodon
$ cd ~/.rbenv/plugins/ruby-build
$ git pull origin master
$ cd /home/mastodon/live
$ rbenv install 2.5.3
$ rbenv rehash
$ rbenv global 2.5.3
$ ruby -v
うまく切り替わらなかったら
$ rbenv init
$ vi ~/.bash_profile
eval "$(rbenv init -)"
の表記があるかどうかチェック。なければ追記する
※要vimコマンド（追記したり上書き保存したり）
$ rbenv local --unset
$ rbenv rehash
$ source ~/.bash_profile
$ ruby -v
2.5.3...が表示されていれば成功
あとはいつものようにMastodonをバージョンアップ。
無事v2.6.0rc1になりました。
・2019年4月10日
個人的な2周年記念で書きました。
・2019年4月17日
これまで動いていたLet’s EncryptのSSL自動更新が今回に限って動かなかったらしく、さらに更新かけようにもエラーが。
けっきょく
# systemctl stop firewalld
でファイアウォールを解除してみたら更新できたという...勉強になりました。
以上がじぶんでやった対応策ですけど、そのあとこちらを参考にして対策を講じました。
・2019年7月1日
サーバーのディスク容量が全体の95％に達することが増えてきました。なのでこのnoteで以前にまとめたディスク容量とパーティションサイズの拡張の方法を行ったのですが、そのときにハマったメモです。
具体的には全文検索のelasticsearch関連のエラーですね。
拡張後にMastodonインスタンスを再起動したところ、直後のログに
Chewy::ImportFailed: Import failed
"reason"=>"blocked by: [FORBIDDEN/12/index read-only / allow delete
などというエラーが頻出するようになりました。そこで調べてみるとこちらの記事に該当するようだとわかりました。
つまり、サーバーのディスク容量が95％に達したことでディスクのしきい値に達してしまい、ディスクを拡張しても解消されない。全てのelasticsearchのインデックスにロックがかかってしまった、ということのようです。
そして参考記事のとおりに
# curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'というコマンドを実行することでエラーが出なくなりました。
おつかれさまでした。
・2019年9月25日
v2.9.3からv3.0.0rc1にバージョンアップしました。
すでにRuby 2.6.4にアップデート済みだったので、あと事前にやったことと言えばこちらの記事で気になった《gccを新しいバージョンにする》ため、下記のインストール作業をしたことです。
# インストール
yum install centos-release-scl
yum-config-manager --enable rhel-server-rhscl-7-rpms
yum install devtoolset-8
# Developer Toolsetを有効にする
scl enable devtoolset-8 bash
vi ~/.bash_profile
# bash_profileを開いたら次の一行を追記
source /opt/rh/devtoolset-8/enable
# bash_profileを保存したらリロード
source ~/.bash_profile
# バージョン確認
gcc --version
g++ --versionyum installによってRed Hat Developer Toolsetをインストールすることで比較的容易にgccをバージョンアップできました。
あとは公式ドキュメントどおりに...。
無事、v3.0.0rc1にバージョンアップ完了しました。
・2019年10月15日
「pg_repack」というPostgreSQL用の拡張機能について記事をまとめました。サーバーのストレージを節約して空き容量を増やす、そんなMastodonインスタンス保守ツールとして愛用しています。
・2020年1月29日
Mastodonのv3.1.0rc1およびv3.1.0rc2が出たのでバージョンアップしましたが、事前にNodeJSというものをv10.13以降にアップデートする必要がありました。
NodeJSのアップデート方法は、わたしのサーバー環境（CentOS 7.7）では以下のとおりです。
# curl -sL https://rpm.nodesource.com/setup_10.x | bash -
# su - mastodon
$ cd live
$ sudo yum install nodejs -y
あとはいつものMastodonバージョンアップ作業をしましたが、途中、pgというRubyGemsのインストール時にpg_configの参照先が見つからない?違う?というエラーが出て、bundle installが中断してしまいました。
そこで
$ bundle config build.pg --with-pg-config=/usr/pgsql-12/bin/pg_config
というコマンドを実行。わたしの環境ではPostgreSQL 12.1を使っているんですけど、pg_configの参照先が旧バージョンになっていたためにエラーが出たようで、上記のコマンドによって正しい参照先に変更しました。
そして再度bundle installを実行。
あとはいつものとおり。
無事にMastodon v3.1.0rc2に移行できました。
・2020年8月14日
PostgreSQL 12.4がリリースされたので、いつものようにサーバーでyum updateしました。そのあとサーバーを再起動し、Mastodonのログを確認したら
PG::Error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 6432? ERROR: no such user: mastodon
というエラーが出ていて、データベースにアクセス不能となったもよう。
ちなみにport 6432は別途インストールしたPgBouncerのために利用しているものなので、そこを重点的に調べたところ、下記の手順で解決しました。
まず、以前にPgBouncerをインストールしたときサーバー上に作成した /etc/pgbouncer 直下の userlist.txt というファイルがなくなっていたので、再作成しました。
そのあと systemctl restart pgbouncer を実行し、Mastodonを再起動。
無事、port 6432にアクセスできるようになり、Mastodonも正常に動きました。
それにしてもPostgreSQLのマイナーバージョンアップでこんなことが起こるなんて...。ちょっとビックリしました。
・2021年2月28日
Mastodonサーバーを閉じました。約4年間とても楽しかったです。おかげでいろんなスキルが身につき、たくさんの出会いと経験、有意義な時間をいただきました。ありがとうございました。
気軽にクリエイターの支援と、記事のオススメができます！
よかったらサポートをお願いします。もしくはギルドハウス十日町へ遊びにいらしていただければうれしいです。