カテゴリー: ガジェット Page 1 of 99

以下の環境でGrowiを利用。

• Growi v7.4.1
• node v20.10.2
• Ubuntu 24.04
• Growi実行環境 /home/www-data/growi
• Growi実行ユーザ：root

v7.4.1で以下の問題点にぶつかったため、growiのスタートアップスクリプトとsystemdで対処したときのメモです。

問題点

• daemon-reload の遅延: 設定反映に約5分を要していました。
• 起動プロセスの停滞: サービス開始から実際にアクセス可能になるまで約6分かかっていました。（以前は数秒）
• 不安定な運用: 異常終了時の自動再起動設定がなく、ログも標準出力のみで追跡が困難でした。

旧設定

• /etc/systemd/system/growi.service

[Unit]
Description = growi
After=network-online.target mongod.service
After=network.target elasticsearch.service
ConditionPathExists=/home/www-data/growi

[Service]
ExecStart=/home/www-data/growi/growi-start.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

• /home/www-data/growi/growi-start.sh

#!/bin/bash

# NVM environmentをロード (NVM_DIRを直接指定)
export NVM_DIR="/root/.nvm" # $HOMEの代わりに直接パスを指定
if [ -s "$NVM_DIR/nvm.sh" ]; then
  \. "$NVM_DIR/nvm.sh"  # nvmをロード
  # 次の行でスクリプト実行時のnodeとnpmのバージョンをログに出力
  echo "NVM for GROWI startup script loaded. Using Node version: $(node -v), npm version: $(npm -v)" > /tmp/growi_nvm_load.log
else
  # NVMが見つからない場合もログに出力
  echo "NVM_DIR ($NVM_DIR) not found or nvm.sh not found for GROWI startup script." > /tmp/growi_nvm_load.log
fi

cd /home/www-data/growi
NODE_ENV=production \
AUDIT_LOG_ENABLED=true \
FORCE_WIKI_MODE=private \
MONGO_URI=mongodb://localhost:27017/growi \
ELASTICSEARCH_URI=http://localhost:9200/growi \
REDIS_URI=redis://localhost:6379 \
PASSWORD_SEED=password \
npm run app:server

原因分析

以下、分析はGemini。

1. systemdの過負荷: ConditionPathExists が大規模なディレクトリ（growi）をチェックする際、OSレベルでスキャン待ちが発生していた可能性。
2. NVMの初期化コスト: 起動のたびに nvm.sh を読み込んでいた。これは数百行のシェルスクリプトを実行する処理であり、本番環境のサービス起動としては非常に重い。
3. プロセスの二重管理: シェルスクリプトが npm プロセスを「子プロセス」として抱えていたため、systemdからの制御効率が悪かった。

何が問題だったのか（ボトルネックの正体）

今回の事象で最大の問題は、「本番環境のサービス起動に、開発環境のような動的な初期化プロセスを組み込んでいたこと」にありました。

具体的には、以下の3つの「待ち」が連鎖していました。

1. システムチェックによる停滞 (ConditionPathExists) systemdのユニットファイルでGROWIのインストールディレクトリをチェックしていましたが、node_modules を含む膨大なファイル群をOSレベルでスキャンしに行った際、I/O待ちやカーネルレベルのオーバーヘッドが発生し、daemon-reload や起動そのものを著しく遅延させていました。
2. シェルスクリプトによる二重起動のオーバーヘッド 起動のたびに nvm.sh をロード（source）し、Node.jsのバージョン判定を動的に行っていました。これは開発時には便利ですが、本番サービスとしては数百行のシェルスクリプトを毎回実行することになり、CPUリソースと時間を無駄に消費していました。
3. プロセスの「親子関係」の不備 systemdから見ると、管理対象が「GROWI本体」ではなく「起動用のシェルスクリプト」になっていました。このため、GROWIが内部でハングアップしてもsystemdが検知できず、再起動もかからないという「運用上の死角」が生まれていました。

これを是正した設定ファイル

設定の前に！

• 設定ファイルのバックアップ

sudo cp -pi /etc/systemd/system/growi.service /path/to/backup/growi.service.$(date +%Y%m%d)

sudo cp -pi /home/www-data/growi/growi-start.sh /path/to/backup/growi-start.sh.$(date +%Y%m%d)

• diffによるバックアップ確認

sudo diff -u /path/to/backup/growi.service.$(date +%Y%m%d) /etc/systemd/system/growi.service 

sudo diff -u /path/to/backup/growi-start.sh.$(date +%Y%m%d) /home/www-data/growi/growi-start.sh

新しいファイル本体

• /etc/systemd/system/growi.service

[Unit]
Description=GROWI Service
After=network-online.target mongod.service elasticsearch.service redis.service
Wants=network-online.target

[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/home/www-data/growi
ExecStart=/bin/bash /home/www-data/growi/growi-start.sh
Restart=always
RestartSec=10
StandardOutput=append:/var/log/growi.log
StandardError=append:/var/log/growi-error.log

[Install]
WantedBy=multi-user.target

• /home/www-data/growi/growi-start.sh

#!/bin/bash

# Node.jsバイナリへのパスを直接追加 (nvm.shのロードを回避して高速化)
export PATH="/root/.nvm/versions/node/v20.19.2/bin:$PATH"
GROWI_DIR="/home/www-data/growi"

cd $GROWI_DIR

# 環境変数の設定
export NODE_ENV=production
export AUDIT_LOG_ENABLED=true
export FORCE_WIKI_MODE=private
export MONGO_URI=mongodb://localhost:27017/growi
export ELASTICSEARCH_URI=http://localhost:9200/growi
export REDIS_URI=redis://localhost:6379
export PASSWORD_SEED=password

# execにより、このシェル自体をnpmプロセスに切り替える
exec npm run app:server

※このpasswordは、旧設定をそのまま利用します。でない場合、「Growiにログインできない」という地獄が待っています。

ファイル差し替え後の挙動

• systemdリロード

sudo systemctl daemon-reload

• growi再起動

sudo systemctl restart growi.service

• growi再起動確認

systemctl status growi.service

active(running) を確認します。

その後、

1. growiが起動する
2. 新しいセッション（ゲストセッション）で管理者アカウントにログインできる
3. 一通りの操作 (Wikiページの作成や編集）が行えればOKです。

設定の比較

■ systemd ユニットファイル (growi.service)

項目	旧設定 (遅延の原因)	新設定 (最適化済)
依存関係	Afterが分散、Redisの指定なし	After/WantsにRedis含め統合
パスチェック	ConditionPathExists (5分停滞の疑い)	削除（高速化に寄与）
実行ユーザ	指定なし (デフォルト)	User=root / Group=root 明示
作業ディレクトリ	スクリプト内で cd	WorkingDirectory で定義
再起動設定	Restart=no (手動復旧が必要)	Restart=always (10秒後に自動復旧)
ログ管理	標準出力のみ (systemdログに混在)	/var/log/growi.log に直接出力

■ 起動スクリプト (growi-start.sh)

項目	旧設定 (遅延の原因)	新設定 (最適化済)
Node環境構築	source nvm.sh (数秒〜数十秒のロス)	PATH を直接追加 (0秒)
環境変数	\（バックスラッシュ）連結 (ミスしやすい)	export 方式 (確実で読みやすい)
実行コマンド	npm run app:server (子プロセスとして実行)	exec npm... (プロセスを置き換え)

4. 対処方法のポイント

• 「動的な環境構築」から「静的なパス指定」へ: 本番サーバでは nvm を毎回読み込む必要はありません。パスを直接通すことが最速の解決策でした。
• systemdの責務を明確にする: ディレクトリの存在チェックやパス移動はスクリプトではなく、ユニットファイルの WorkingDirectory 等に任せることで、systemdの管理サイクルが正常化しました。
• プロセスの直結 (exec): OS (systemd) -> Bash -> npm となっていた階層を、exec で OS (systemd) -> npm に直結させたことで、シグナルの伝達やメモリ効率が改善しました。

今後のメンテナンス

Node.jsのバージョンを変更した際のみ、growi-start.sh 内の v20.19.2 というパス文字列を書き換えるだけで対応可能です。

概要

Growi 7.2.x → Growi 7.4.0にアップデートする 手順です。

※ Growi7.3.3より前のバージョンは脆弱性が存在します。Growiをインターネットで公開している方は、こちらの手順で上げましょう。

注意点

• Growi 7.4.xはElasticSearchがv9でなければ動きません。
• また、mongodbの最新版は、古いCPUでは動きません。
• 上記理由のためGrowiをインターネット環境で動かしている場合は以下を十分検討ください。
  • WAFなどで防御する。
  • ハードウェア環境を最新のmongodb / Elasticsearchが動くものへとアップグレードする。
  • インターネット公開を諦める。

前提

• 既にgrowi v7.1.x/v7.2.xをインストールしていること。
• 管理画面トップやトップページ右下からバージョンが7.1.xまたは7.2.xであることを再確認します。
• systemdによってサービス化されていること。
• 具体的な手順はhttps://atelier.reisalin.com/projects/zettel/knowledgebase/articles/105
• 最新版や安定版がリリースされていることを以下のサイトで確認していること。
• https://github.com/growilabs/growi/releases
• ※設定ファイルの変更やパッケージインストールの変更、nodeのバージョンアップの必要等があれば、それも事前に済ませます。

さっくりはならない手順

1. Growiをメンテナンスモードにします。
2. Growi・Elasticsearchのサービスを停止します。
3. バックアップを取ります。
4. gitコマンドで最新版をcheckoutします。
5. アップグレードを行います。
6. Elasticsearch・Growiのサービスを再開します。
7. Growiのメンテナンスモードを解除します。
8. アップグレードされたことを確認します。

メンテナンスモード有効化

1. Growiに管理者権限でログインします。
2. 管理トップ＞アプリ設定に進み、「メンテナンスモードを開始する」をクリックします。
3. トップページに戻り「メンテナンスモード」が表示されていることを確認します。

バックアップ

以下をバックアップします。

• mongodbの格納データ

cat /etc/mongod.conf |grep dbPath

として、ここのディレクトリ一式を控えます。(筆者環境 /home/mongodb)

このディレクトリを任意の方法でバックアップします。

• Growiの添付ファイル一式が納められているディレクトリ（ファイルアップロード先をlocalにしている場合のみ)

/growi/root/directory/apps/app/public

(筆者環境 /home/www-data/growi/apps/app/public)ここも念のためバックアップします。

※ 添付ファイルのアップロード先をAWSやAzureなどにしている場合は不要です

• vpsや仮想ゲストの場合はシステム全体：推奨

スナップショット機能などでシステム全体をバックアップした方が確実で安心です。

ElasticsearchとGrowiの停止

• Elasticsearchサービス停止

sudo systemctl stop elasticsearch.service

• サービス停止確認

systemctl status elasticsearch.service

inactive(dead)を確認します。

• Growiサービス停止

sudo systemctl stop growi.service

• サービス停止確認

systemctl status growi.service

inactive(dead)を確認します。

作業前バックアップ

• データディレクトリを丸ごとコピー (-aオプションでパーミッションを維持)

sudo cp -a /var/lib/elasticsearch/ /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)

自分の環境に合わせます。

• バックアップ確認

sudo ls -l /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)

バックアップした内容があることを確認します。(※管理者権限でないとこのディレクトリを見ることはできません)

リポジトリ設定ファイル名をv9用に変更

Elasticsearchのバージョンを指定するリポジトリをv9に変更します。

• 現行のリポジトリリストをバックアップ

sudo cp -pi /etc/apt/sources.list.d/elastic-8.x.list /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d)

• リポジトリリストのバックアップ確認

diff -u /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d) /etc/apt/sources.list.d/elastic-8.x.list

• リポジトリリストの名前変更

sudo mv /etc/apt/sources.list.d/elastic-8.x.list /etc/apt/sources.list.d/elastic-9.x.list

• リポジトリリストの名前変更確認

ls -l /etc/apt/sources.list.d/elastic-9.x.list

ファイルがあることを確認します。

sedコマンドでファイル内の参照先を8.xから9.xに書き換え

sudo sed -i 's/8.x/9.x/g' /etc/apt/sources.list.d/elastic-9.x.list

Elasticsearchのアップグレード

• パッケージ全体のバックアップ

sudo aptitude update

好みでaptitudeを用いています。必要に応じてaptを用いてください。

• Elasticsearchのアップグレード

sudo aptitude upgrade elasticsearch

※ Growiインストール時、/etc/elasticsearch/jvm.optionsファイルなどの設定変更を行っているため、アップグレード時の設定ファイルを残すかどうかの確認では、必ずN（残す）を選択します。

• プラグインのアンインストール

Growiに必要なElasticsearchのプラグインは自動更新されません。この処置を執らないとせっかくアップグレードしたのに起動しないという事態が発生します。

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji

• プラグインの再インストール

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji

growiディレクトリに移動します

cd /home/www-data/growi && pwd

自分の環境に合わせます。(筆者環境/home/www-data/growi)

リリースタグを確認します。

• リリースタグ取得

sudo git fetch --tags

• リリースタグ確認

sudo git tag -l

スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。

チェックアウトとインストールを行います。

• 変更を一時的に退避

sudo git stash

• チェックアウト

sudo git checkout 【バージョン】

リリースタグは再確認しましょう。今回は 2025/12/24 リリースされたv7.4.0を選択しました。

• pnpm install

sudo pnpm i

• ビルド

sudo npm run app:build

ElasticsearchとGrowiの再開

• Elasticsearchサービス開始

sudo systemctl restart elasticsearch.service

• サービス開始確認

systemctl status elasticsearch.service

active(running)を確認します。

• バージョンアップ確認

curl -X GET "localhost:9200"

"number" : "9.1.3",など、9系にアップグレードされていることを確認します。

• Growiサービス開始

sudo systemctl restart growi.service

• サービス開始確認

systemctl status growi.service

active(running)を確認します。

メンテナンスモード無効化

1. Growiに管理者権限でログインします。
2. 管理トップ＞アプリ設定に進み、「メンテナンスモードを終了する」をクリックします。
3. トップページに戻り「メンテナンスモード」が表示されていないことを確認します。

バージョンアップを確認します。

1. 画面下部にあるバージョンがチェックアウトしたバージョン(v7.4.x)であることを確認します。
2. 各種機能（ページ閲覧や編集）などが正常に行えるかを確認します。

バージョンアップ後の作業

必要に応じてバックアップしたファイル一式やスナップショットを削除します。