パルワールドのサーバーを24時間動かし続ける：自動起動・自動再起動・定時再起動

「24時間動かしっぱなしにする」は設定一つではなく、性質の違う三つの仕組みです。起動時に自動で立ち上がること、落ちたときに立ち上がり直すこと、そしてまだ落ちていないうちに自分から止めて起こし直すこと。三つのうち一つを抜かすと、抜かしたその一点でぴたりと止まります。この記事では三つの仕組みに加えて、動かし続けたサーバーでメモリが実際にどう動くか、セーブを失わずに再起動する手順、そして逆の問い、つまり誰もいない時間にワールドを動かしておく必要がそもそもあるのか、までを扱います。サーバーをまだ作っていないなら専用サーバーの立て方を先にどうぞ。

常時起動が意味する三つのこと

止まり方は三通りあり、それぞれ別の仕組みが受け持ちます。

三つは互いの代わりになりません。Restart=on-failure は起動時の自動実行とは何の関係もなく（それは enable の仕事です）、enable は一時間前に死んだプロセスを生き返らせてくれず、どちらもメモリが埋まっていく間は何もしません。その間はまだ何も失敗していないからです。「自動再起動を入れてあるのになぜ落ちているのか」は、たいてい入れていない残りの一つが原因です。

そして人の手が要る四つ目があります。止まったことに気づくことです。三つ全部を入れても三つとも外れる夜は来るので、最後は誰がどれだけ早く気づくかが残ります。

systemd ユニットが見てくれる範囲と、その外側

ユニットファイルは専用サーバーの立て方のものに、[Unit] セクションへ二行足して使います。この記事に関わるのは次の行です。

[Unit]
StartLimitIntervalSec=600
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

WantedBy=multi-user.target と sudo systemctl enable palworld の組み合わせが起動時の自動実行です。立て方に出てくる enable --now の --now は「ついでに今も起動する」という意味しかないので、enable を飛ばして start だけしていると、今は問題なく動いていても、次の再起動で消えます。これは頭の中では確かめられない種類の失敗なので、誰もいない時間に一度は本当に sudo reboot して、自動で戻ってくるかを確かめてください。

Restart=on-failure が面倒を見てくれるのは、0以外の終了コードと、シグナルで死んだ場合です。メモリを使い切ってカーネルにプロセスを強制終了されるのは後者に入ります。

見てくれないのは次の三つです。

1. 正常終了（コード0）。REST API 経由で落としたサーバーはきれいに終わるので、on-failure はあえて手を出しません。「スクリプトが止めたところまではいいのに起動し直してくれない」の九割はこれです。
2. 生きているのに応答しない状態。systemd が見ているのはプロセスであってゲームではありません。入れるけれど誰も動けない状況でも、ユニットから見れば active のままです。
3. 繰り返す失敗。StartLimit の二行があると、10分のあいだに5回起動に失敗した時点で systemd は諦め、failed で止まります。systemd 自体の既定は「10秒のあいだに5回」で、RestartSec=10 で毎回10秒待つユニットでは決して届きません。二行がなければ、毎回同じ理由で死ぬサーバーは activating (auto-restart) のまま延々と再試行を続けます。systemctl status palworld に「start request repeated too quickly」が出ていたら、自動復帰が壊れているのではなく、毎回同じ理由で死んでいるからログを見ろという意味です。

三つ目を、この二行を消したり StartLimitIntervalSec=0 にしたりしてごまかさないでください。壊れたセーブを読めずに起動できないサーバーが10秒おきに永遠に再試行するだけで、そのあいだに本当の原因は何千行も下へ流れていきます。journalctl -u palworld -n 100 で最後の失敗理由を読むほうが、いつでも速いです。

動かし続けたサーバーのメモリは実際どうなるか

パルワールドのサーバーには、アーリーアクセスの頃に「プロセスが殺されるまでメモリが増え続ける」という評判がつき、再起動をめぐる助言の多くはいまもそれを前提にしています。ここに載せるのは、こちらで運用しているサーバーのうち利用の多い一台が実際にどう動いたかです。毎日一回再起動しているサーバーで、期間は2026年10月の10日間、数字は監視で取ったメモリ使用量です。

ここから読み取れる二つのことは、どんな経験則より役に立ちます。

• 増えるのは遊んでいる間で、遊んでいなければ止まります。ふだんの一日では、再起動から次の再起動までに0.5〜1.5GB 増えました。人の少ない日は、約3.2GB のまま何時間も横ばいでした。
• 一日の最高値は、日を追って上がっていきませんでした。再起動のたびに同じ水準まで戻りました。

この数字から分からないのは、一度も再起動しなかったらどうなるかです。こちらで動かしているサーバーはすべて毎日再起動しているので、その答えは持っていません。自分のワールドで増え続けるかどうかは、決めつけずに測ってください。どちらにしても毎日の定時再起動は安い保険で、毎晩メモリを元の水準に戻し、セーブとアップデートに決まった時刻を与えてくれます。

メモリはどこに消えているか

パルワールドのサーバーのメモリは三つに分けられ、それぞれ答える問いが違います。

1. 基礎消費。起動した時点からサーバーが抱えているぶんで、1.0以降は増えています。海上拠点は泳ぐパルと飛ぶパルの経路探索を加え、天空の島と世界樹は追加の読み込み領域です。これが下限です。
2. オンラインのプレイヤー。描画距離と探索範囲のぶんです。ログアウト後に一部は戻りますが、全部ではありません。
3. ワールドに溜まったもの。拠点、建築物、働いているパル、地面のドロップ品。プレイヤーが抜けてもすべてシミュレーションされ続けます。ワールドが長く続くほど育つのはこの部分で、辞めた人は拠点を持って帰ってくれません。

前の二つは、満員の一晩にどれだけのメモリが要るかを決めます。三つ目と、エンジンが手放さないぶんが、どのくらいの頻度で再起動する価値があるかを決めます。

自分のサーバーの数字を読む

再起動しても何も変わらないなら、別の場所を見てください。マシンがそもそも足りていないか、全員が感じているのはサーバーではなく回線のほうです。誰が感じているかからサーバー自身のフレームレートまで順にたどる道筋はサーバーが重い：原因の切り分け方にまとめています。

いちばん痛いのはメモリ不足による強制終了です。カーネルに強制終了された瞬間にセーブ書き込み中だった可能性があり、途中まで書かれた Level.sav には次に起動するまで気づけません。メモリとバックアップを同じ話として扱うべき理由がここにあります。

抱えるメモリの量を変える設定

どれも PalWorldSettings.ini のあの一行の中にあります（安全な編集方法は設定の全項目解説を参照）。

逆に、やってはいけないこともあります。

• bIsUseBackupSaveData を切らないでください。メモリを食っているわけではなく、何かが壊れた日に戻る道の一つです。
• ServerReplicatePawnCullDistance を5000未満にしないでください。公式の下限で、それより下げるとプレイヤーには止まったままのパルが見えます。
• 一台のマシンで二つのパルワールドサーバーを動かさないでください。

どのくらいの頻度で再起動するか

スペック表から読み取れる間隔はありません。ワールドが余裕を食う速さ次第で、それはどれだけ建てたか、襲撃がオンか、一日中誰かがいるかで決まります。一日一回から始め、実際に測った結果で調整してください。

固定メンバーのサーバーなら、実用的な答えは誰も遊んでいない時間帯に一日一回です。それより頻繁な再起動が要るかもしれないのは、一日中誰かがいる公開サーバーです。

告知して、数えて、保存してから止める

kill や systemctl kill、あるいは電源ボタンで落とすのは、毎日クラッシュを一つ自作しているのと同じです。自動保存の間隔ぶんの進行が消え、運が悪ければ書き込みの最中に当たって Level.sav が半分だけ書かれた状態になります。半端なセーブは次の起動まで表に出てこないので、気づくのは一日あとです。

正しい止め方は四段階、告知 → カウントダウン → 強制セーブ → 停止で、すべて公式の REST API にあります。まず PalWorldSettings.ini で API を有効にし、ローカルホストにだけ開きます。

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="十分に長いパスワード"

認証は HTTP Basic で、ユーザー名は常に admin、パスワードは AdminPassword です。開発元は公式リファレンスでこの API をインターネットに直接公開する設計ではないと明言しているので、ファイアウォールで8212を開けないでください。RCON は非推奨になったので新しいスクリプトの土台にはせず、エンドポイントの一覧はREST API の使い方を見てください。

PW='十分に長いパスワード'
API='http://127.0.0.1:8212/v1/api'

# 先にワールドをディスクへ書き出す
curl -s -u "admin:$PW" -X POST "$API/save" -d ''

# 告知とカウントダウンは API がやってくれる
curl -s -u "admin:$PW" -X POST "$API/shutdown" \
     -H 'Content-Type: application/json' \
     -d '{"waittime":60,"message":"Server is going down in 60 seconds"}'

message はチャット欄に流れて見落とされる一行ではありません。全員の画面の中央に、横帯の通知として表示されます。

/stop は予告なしで即座に切るほうなので、日常の運用に使わないでください。/shutdown は指定した時間だけ待ってから、正しい手順で停止します。先に保存するのは、shutdown が停止時に自動でセーブするかどうかを公式リファレンスが明言していないからです。

そしてここで、systemd の節で触れた落とし穴が効いてきます。/shutdown で停止したプロセスは正常終了なので、Restart=on-failure は立ち上げ直してくれません。目的が再起動なら、API には保存と告知までをやらせて、最後は sudo systemctl restart palworld に任せます。目的が本当に停止（メンテナンス、引っ越し、誰も遊ばない一週間）なら /shutdown だけで十分です。深夜に落ちてそのまま戻ってこない事例は、この区別ができていないケースがいちばん多いです。

毎日の定時再起動をスクリプト一本で

#!/bin/bash
# /home/palserver/restart.sh：告知、保存、再起動
PW='十分に長いパスワード'
API='http://127.0.0.1:8212/v1/api'

curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Server restarts in 5 minutes for maintenance"}'
sleep 240
curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Saving and restarting in 60 seconds"}'
sleep 60
curl -s -u "admin:$PW" -X POST "$API/save" -d ''
sleep 10
sudo systemctl restart palworld

管理者パスワードが入るので、このスクリプトは chmod 700 しておきます。cron で毎日午前四時に回します。

0 4 * * * /home/palserver/restart.sh >> /home/palserver/restart.log 2>&1

systemd で揃えたいならタイマーでも書けます。

# /etc/systemd/system/palworld-restart.timer
[Unit]
Description=Restart Palworld daily

[Timer]
OnCalendar=*-*-* 04:00:00

[Install]
WantedBy=timers.target

同じ名前の palworld-restart.service（Type=oneshot）がこのスクリプトを呼び、sudo systemctl enable --now palworld-restart.timer で有効になります。次の実行時刻は systemctl list-timers で確認できます。Persistent=true は入れないでください。マシンが止まっていて逃した実行を起動直後に埋め合わせるオプションですが、二分前に立ち上がったばかりのサーバーを再起動する理由はありません。時刻は誰もいない時間帯にして、バックアップが走る時刻と重ならないようにだけ気をつけます。

Windows も考え方は同じです。PowerShell の Invoke-RestMethod で announce と save を順に叩き、Stop-Process で PalServer-Win64-Shipping を止めて PalServer.exe を起動し直し、タスク スケジューラで毎日実行させます。

どうせ毎日一度止めるので、その停止は新しいゲームビルドを確認するのにいちばん手間のかからないタイミングです。確認の組み込み方、その前に置くべきバックアップ、新しいビルドでワールドが読み込めないときの対処はパルワールド専用サーバーのアップデート方法にまとめています。

落ちたことにどうやって気づくか

既定の監視は「プレイヤーが教えてくれる」で、その通知は金曜の夜十時に五人が待っているという形で届きます。もっと安い方法が三つあります。

状態を一行で。systemctl is-active palworld は active か failed しか返しません。理由まで見たいときは、その日のジャーナルから終了の記録だけ取り出します。

systemctl is-active palworld
journalctl -u palworld --since today | grep -i "main process exited"

ポート。ゲームのポートは UDP 8211なので、ブラウザで開いて確かめられません。実際に待ち受けているかは ss -lunp | grep 8211 で見ます。

1分ごとのハートビート。ローカルの cron が毎分 /metrics を叩き、失敗したら自分が実際に見る場所へ一行だけ送るようにします。cron はシェルで設定した PW を引き継がないので、パスワードは小さなスクリプトに書き、crontab の行はそのスクリプトを呼ぶだけにします。

#!/bin/bash
# /home/palserver/heartbeat.sh：cron が毎分呼ぶ
PW='十分に長いパスワード'
curl -sf -m 10 -u "admin:$PW" http://127.0.0.1:8212/v1/api/metrics >/dev/null || /home/palserver/alert.sh

-m 10 を付けておくと、生きているのに応答しないサーバーも落ちたものとして扱えます。chmod 700 /home/palserver/heartbeat.sh で自分以外が読めないようにしてから cron に載せます。

* * * * * /home/palserver/heartbeat.sh

外部の死活監視サービスに任せたいからといって8212をインターネットに開けるのはやめてください。監視と引き換えにサーバーの管理権限を丸ごと渡す取引になります。ハートビートはマシンの中で回し、外に出るのは通知の一行だけにします。

自動一時停止が指す二つのもの

ときには問いが逆向きです。一日ぶりにログインしたら、パルの半分は空腹、二匹は病気、箱には頼んでもいない鉱石が山積み。その間ずっと誰も接続していないのに、ワールドだけが動き続けていたわけです。専用サーバーは最後の一人が抜けても休みに入らず、満員のときと同じ周期でワールドを計算し続けます。いつでも入れるのはそのおかげで、誰も入らない時間にも同じだけワールドが歳を取るのも同じ理由です。ゲーム内でワールドを開く方式（一人が開いて残りが入る形）から移ってきたなら、ここで習慣がずれます。あちらはその人が終了すればワールドも止まるからです（二つの方式がワールドをどこに置くのかはパルワールドのマルチプレイ方式の比較にあります）。

この話をすると勧められるのが自動一時停止ですが、この言葉は別々の二つの機能を指しています。料金を止めるほうは、誰も接続していない区間は課金しない方式です。ワールドもたいていは一緒に止まりますが、この機能が売りにしているのは価格です。ワールドを止めるほうは、ゲーム内の時間が進まなくなる方式です。パルは食べず、作物は育たず、襲撃も来ません。どちらの機能なのかは、次の二つを聞けば分かります。一時停止中にワールドは進むのか、そしてまた遊べるようになるまでどれだけかかるのか。

自動一時停止は実際にどう動いているのか

出回っている自動一時停止の多くは、OS のシグナル二行でプロセスを凍らせています。

kill -STOP <pid>   # その場で凍らせる
kill -CONT <pid>   # 続きから動かす

SIGSTOP はパルワールドのコマンドではなく、ゲームはそんなことが起きたことすら知りません。カーネルがそのプロセスに CPU を割り当てなくなるだけです。メモリも開いたファイルも UDP ポートも握ったまま実行だけしない状態になり、SIGCONT を受けると止まった命令の位置から再開します。

この二行を安全に使うには、周りにあと三つの仕組みが必要です。

1. 凍らせる前に強制セーブ。SIGSTOP はプロセス側で捕捉できないので、ディスクに書き出されていないものはメモリに残ったままになります。その状態で電源が落ちれば、その分は消えます。
2. 誰かがネットワークを見張る必要があります。凍ったプロセスは人が来たことに気づけないので、別の何かが root で動いて入ってきたパケットを監視し、SIGCONT を送ります。
3. 一覧に残す役も要ります。サーバーがゲーム側のバックエンドに送っていた合図も一緒に止まるので、凍ったサーバーはコミュニティサーバー一覧から消えます。何かがそのサーバーのふりをし続けない限り、戻りません。

どれも発売元が用意した機能ではありません。公式 REST API にあるのは /save、/shutdown、/stop、/announce、キックと BAN で、一時停止はありません。自宅のマシンなら妥当な選択です。目的が電気代の節約だからです。ただ、運用を人に預けているサーバーでは、別の方法でも得られる結果のために、上の三つの仕掛けを買うことになります。

もっと単純なやり方：止めてしまう

「一時停止」で望まれているのは、ほとんどの場合「遊んでいない間はワールドも動かないでほしい」ということです。サーバーを止めれば、それがそのまま手に入ります。ワールドはディスクに保存され、実行されるものがない以上ゲーム内の時間は進みようがなく、起動し直せばそのセーブから続きます。安全に止める順番は、上の節で書いた「先に保存してから /shutdown」の組み合わせです。代償も正直に書いておくと、戻るのに一瞬ではなく、起動とワールド読み込みの分だけかかります。夜に集まって遊ぶ仲間内なら、先に来た人が起動すれば済みます。

止めるほうを自動化する

自動でやってほしいなら、自動化するのは止めるほうで、凍らせるほうではありません。サーバーに今何人いるかを5分おきに聞くタイマーがあれば済みます。

#!/bin/bash
set -o pipefail
PW='十分に長いパスワード'
API='http://127.0.0.1:8212/v1/api'
STATE=/var/lib/palworld-empty-rounds
MAX=6   # 6回 x 5分 = 30分無人

n=$(curl -sf -u "admin:$PW" "$API/metrics" | jq -r '.currentplayernum') || exit 0
case "$n" in ''|*[!0-9]*) exit 0 ;; esac   # 数値でなければ何もしない
[ "$n" -gt 0 ] && { rm -f "$STATE"; exit 0; }

rounds=$(( $(cat "$STATE" 2>/dev/null || echo 0) + 1 ))
echo "$rounds" > "$STATE"
[ "$rounds" -lt "$MAX" ] && exit 0

curl -s -u "admin:$PW" -X POST "$API/save" -d ''
curl -s -u "admin:$PW" -X POST "$API/shutdown" \
     -H 'Content-Type: application/json' \
     -d '{"waittime":10,"message":"接続者がいないためサーバーを停止します"}'
rm -f "$STATE"

落とし穴は最初の二つのチェックです。問い合わせの失敗は、サーバーが空という意味ではありません。ところがパイプが返すのは curl ではなく jq の終了コードで、jq は死んだエンドポイントに null と答えて平然と終わります。pipefail と数値チェックが無ければ、その null が「0 より大きくない」と判定され、ポートが一度つまずいただけで十人入っているサーバーが落ちます。カウンタをファイルに置いているのは、再起動が数えかけのカウントを残さないようにするためです。

難しいのは、戻すほうです。ここで紹介した仕組みでは、サーバーを起動し直すことはできません。止まったマシンには、頼みを聞く耳がそもそも無いからです。止めるのは cron 一行、起こすのは誰かの判断。凍らせる方式が存在する理由は、まさにこの非対称にあります。

どちらも要らないかもしれません

気になっているのが「ワールドが進んだこと」全体ではなくその一部なら、設定ファイルでその部分だけを直接調整できます。一時停止と違って、遊んでいる間にも効きます。PalStomachDecreaceRate を下げればパルが空腹になるのが遅くなり（綴りが違うのはゲーム側です）、bEnableInvaderEnemy をオフにすれば誰も守れない拠点に襲撃が来なくなり、WorkSpeedRate を下げれば留守の間に拠点が生み出す量が減ります。

自宅のマシンには越えられない壁が二つある

停電。一度の停電は kill -9 一回と同じで、セーブ書き込み中に当たる可能性もあります。UPS で稼げるのは数分で、その数分は「電源が切れたら順番に停止する」ことに使ってはじめて意味を持ちます。つまり UPS の監視デーモンが停電を検知したときに、上の停止手順を呼ぶところまで繋いで完成です。電気が戻ったあとマシンが自分で起動するかどうかも OS の設定ではなく、BIOS の電源復帰の項目で決まります。再起動の確認と同じで、これも一度は本当にコンセントを抜いて確かめないと確かめたことになりません。

動的 IP。家庭用回線のグローバル IP は予告なく変わり、変わった瞬間に友達が保存している アドレス:ポート はすべて使えないアドレスになります。DDNS でホスト名を追従させることはできますが、パルワールドのクライアントに残るのは入力した文字列なので、結局一度は全員が入れ直します。これにルーターの再起動、上りの帯域、回線事業者側のアドレス共有が重なると切り分けが長くなるので、その順番は接続トラブルの切り分けにまとめてあります。

どちらも設定を工夫して越える種類の問題ではありません。自宅のマシンで数日持たせるのは普通にできますが、無人で数か月持たせようとすると、この二つが毎回立ちはだかります。

よくある質問

パルワールドのサーバーを24時間動かし続けるにはどうすればいいですか？

三つを別々に用意します。systemd ユニットを enable して起動時の自動実行にすること、ユニットに Restart=on-failure を入れて落ちたときの自動復帰を作ること、タイマーか cron で一日一回の定時再起動を仕掛けること。どれか一つだけでは、残り二つの場面では止まったままになります。

サーバーが落ちた（鯖落ち）ときに自動で再起動させられますか？

できます。ユニットの [Service] に Restart=on-failure と RestartSec=10 を書けば、クラッシュやメモリ不足で死んだ10秒後に立ち上がり直します。[Unit] にも StartLimitIntervalSec=600 と StartLimitBurst=5 を入れておくと、毎回同じ理由で落ちるサーバーが延々と回り続けず、10分で5回失敗した時点で止まります。一日に何度も発動するなら、見るべきは再起動の設定ではなく、落ちる直前のメモリとログのほうです。

自動再起動を設定したのにサーバーが戻ってきません。何を見ればいいですか？

まず systemctl status palworld です。「start request repeated too quickly」なら10分のあいだに5回失敗して systemd が諦めた状態で、本当の原因はログにあります。直したら sudo systemctl reset-failed palworld で回数を戻してから起動します。状態が activating (auto-restart) から変わらないなら StartLimit の二行が抜けていて、再試行を繰り返しています。エラーもなく静かに inactive なら正常終了で、on-failure が意図して手を出さなかった場合です。その場合はスクリプトの最後の一行を systemctl restart に変えれば直ります。

パルワールドのサーバーはなぜメモリが増え続けるのですか？

主な理由は、人が遊んでいる間にワールドが抱えるものが増えるからです。プレイヤーが探索した範囲と、全員がログアウトしてもシミュレーションされ続ける拠点、働くパル、ドロップ品です。こちらで運用している毎日再起動のサーバーでは、ふだんの一日で0.5〜1.5GB 増え、人の少ない日は横ばいのままで、一日の最高値は10日間を通して3.3〜4.5GB に収まり、日を追って上がってはいきませんでした。毎日の定時再起動が、毎晩それを元の水準に戻します。

パルワールドのサーバーはどのくらいの頻度で再起動すべきですか？

静かな時間帯に一日一回から始めてください。判断基準は再起動直前の余裕で、五分の一を切ったらまず襲撃をオフにし、それから間隔を縮めるかメモリを足します。

メモリを増やせばサーバーが落ちなくなりますか？

一日の最高値でメモリが足りなくなっている場合だけです。毎日の定時再起動の直前にメモリを見てください。最高値でも余裕があるのに落ちるなら、メモリを増やしても変わらず、何が原因かはログか dmesg が教えてくれます。最高値が上限に張り付いているなら、メモリを増やすのがまさに正解です。

自動一時停止はパルワールドの標準機能ですか？

いいえ。専用サーバーに一時停止コマンドはなく、公式 REST API にもそのエンドポイントはありません。自動一時停止として売られているものは、すべてゲームの外側でやっていることです。OS のシグナルでプロセスを凍らせるか、サーバーを止めて必要なときに起動し直すか、どちらかになります。

サーバーを止めればパルは空腹にならずに済みますか？

止まっている間はそうです。空腹を含め、ワールドでは何も進みません。ただし遊んでいる時間については何も変えません。戻るたびに餌箱が空なのが問題なら、PalStomachDecreaceRate のほうが何も止めずに解決します。

自宅の PC でパルワールドのサーバーを24時間動かしても大丈夫ですか？

数日なら問題ありません。長く続けると停電と動的 IP で止まります。停電は予告なしの強制終了なのでセーブが壊れることがあり、グローバル IP が変わると全員が保存した接続先が無効になります。どちらも設定では越えられないので、常設にするなら電源と回線を別の誰かが維持しているマシンが要ります。

レンタルサーバーでは三つがどこにあるか

ここまでの話をレンタルサーバーに移すと、こうなります。起動時の自動実行は、そもそも作業として存在しなくなります。マシンとゲームのプロセスをまとめて預ける形だからです。落ちたプロセスは自動で立ち上げ直されます。毎日の定時再起動は、コンソールのマイサーバーからサーバー詳細に入ったところに、スイッチと時刻として置いてあります。その時刻が近づくとゲーム内にサーバーアナウンスが流れ、カウントダウンが終わってから強制セーブが入り、そのあとで再起動します。手動の停止と起動も同じページのボタン一つで、裏では同じ告知 → セーブ → 停止の順番（安全な停止処理）が走るので、「今週はとりあえず止めておく」を賭けではなく習慣にできます。バックアップは決まった間隔で走り（完全なバックアップに入るもの）、フレームレートとオンライン人数は毎分記録されるので、止まっていた区間はログを掘らなくてもグラフの空白として見えます。

無いのは自動の待機停止です。接続人数を見張って代わりに止めてくれる仕組みはありません。KeepWorlds のパルワールド専用サーバーでこれらが置かれている場所は、いま書いたとおりです。自分で立てる道を選ぶ場合でも、確認する項目は同じです。enable を一度、Restart を一行、先に保存してから回す毎日の再起動を一つ、そして気づく手段を一つ。