Jenkins on Amazon Linux 2023 の /tmp 容量不足対策完全ガイド

Amazon Linux 2023 の /tmp が tmpfs としてマウントされる仕組み

Amazon Linux 2023 は起動時に /tmp を揮発性メモリディスク（tmpfs）として自動的にマウントします。
この設計はシステムのクリーンさと高速な I/O を確保するためですが、RAM の消費が直接増える点で大容量の一時ファイルを扱う CI ツールでは注意が必要です。本セクションではデフォルト設定の根拠と、Jenkins で顕在化した課題について整理します。

背景とデフォルト設定

Amazon Linux 2023 の tmpfs デフォルトサイズは 物理メモリの 50 % に制限されています。
この上限は systemd の DefaultTmpSize= が未指定の場合に自動的に適用される挙動で、公式ドキュメント（systemd‑tmpfiles(5)）にも「デフォルトでは物理メモリの半分まで」という記述があります。たとえば t3.medium (4 GiB RAM) では /tmp が最大 2 GiB になる仕組みです。

Jenkins で顕在化する問題点

Jenkins のビルドプロセスは一時的に数 GB ものアーティファクトやキャッシュを生成します。
/tmp が RAM に依存していると、以下のような障害が頻発します。

• ビルド中に「No space left on device」エラーが発生し、ジョブが即座に失敗する
• エージェントノードが /tmp の容量不足でオフラインになる → 全体の CI パイプラインが停止

このようなリスクを回避するためには、/tmp のサイズ上限を緩和するか、別途永続ストレージへ一時領域を切り替える 必要があります。

現在の /tmp 容量・使用状況を確認する方法

トラブルシュートの第一歩は実際にマウントされているサイズと利用率を把握することです。ここでは代表的な 2 つのコマンドを紹介します。

df -h による容量確認

df -h はファイルシステムごとの総容量・使用量・空き容量を人間が読みやすい単位で表示します。
出力例とポイントは以下の通りです。

• Size が tmpfs に割り当てられた上限（この例では 2 GiB）
• Use% が 70 % を超えていると、残りの空きが少なくなるリスクが高まります

この情報を元に、サイズ増加や別領域への切替えが必要か判断します。

mount コマンドでオプション確認

mount | grep /tmp で実際のマウントオプションを取得できます。
オプションに含まれる size= が現在有効な上限です。

• size=2G がシステム起動時に決定された上限
• nosuid、noexec などのセキュリティフラグも同時に確認でき、変更が必要な場合は合わせて検討します

これら二つのコマンドで得た情報を踏まえて、次の章で示すサイズ変更手順へ進みます。

/tmp のサイズ上限変更と永続化手順

容量不足を解消する方法は大きく分けて 一時的に systemd 設定で上書き する方法と、再起動後も有効になる fstab に記述 する方法があります。目的や運用ポリシーに合わせて選択してください。

systemd tmpfiles.d を利用した一時的な上書き

systemd は /etc/tmpfiles.d/ 以下の設定ファイルを優先して読み込みます。この仕組みを使えば、既存の fstab を触らずにサイズだけを書き換えられます。

1. 設定ファイル作成（例：10 GiB に拡張）

bash
sudo tee /etc/tmpfiles.d/tmp.conf <<'EOF'
d /tmp 1777 root root 10G
EOF

1. systemd-tmpfiles-setup.service を再起動して新しい設定を適用

bash
sudo systemctl restart systemd-tmpfiles-setup.service

1. マウント情報の確認

bash
mount | grep /tmp
# 期待出力例: tmpfs on /tmp type tmpfs (rw,size=10G,mode=1777)

ポイント
この手順は systemd のみが管理する環境で有効です。systemctl restart systemd-tmpfiles-setup.service は /tmp を再マウントしますが、既に起動中のプロセス（例：Jenkins エージェント）は新しいサイズを即座に認識しません。エージェントは サービスの再起動 が必要です。

/etc/fstab へ設定を書き込んで永続化

システム全体で確実に同じサイズを適用したい場合は fstab にエントリを追加します。fstab はブート時にカーネルが最初に読むため、systemd が無効化されても有効です。

1. 現行ファイルのバックアップ

bash
sudo cp /etc/fstab /etc/fstab.bak

1. fstab に新しいエントリを追記（例：12 GiB）

bash
echo "tmpfs /tmp tmpfs defaults,size=12G 0 0" | sudo tee -a /etc/fstab

1. 再マウントまたは再起動

bash
# 再マウントだけで済む場合
sudo mount -o remount /tmp

# 完全に確実にしたいときは再起動
sudo reboot


1. 変更が反映されたか確認

bash
df -h /tmp
# Size が 12G と表示されれば成功

注意点
fstab に書いた場合、インスタンス再起動時に新しいサイズでマウントされますが、既存の Jenkins エージェントは再起動しないと新しい /tmp を使用できません。エージェントをシステムサービスとして管理しているなら systemctl restart jenkins、手動で起動している場合はプロセス停止→再起動が必要です。

大容量一時領域の代替案：EBS ボリュームを活用する

tmpfs の上限を緩めても RAM に依存したままになるため、根本的な解決策として 永続ディスク（EBS） を利用した別ディレクトリへ一時領域を切り替える方法があります。

EBS ボリュームサイズ拡張手順

1. AWS CLI またはコンソールでボリュームサイズ変更

bash
aws ec2 modify-volume --volume-id vol-0abcd1234efgh5678 --size 30

1. 拡張完了を待機

bash
aws ec2 wait volume-modified --volume-id vol-0abcd1234efgh5678

1. OS 側でパーティション・ファイルシステムのリサイズ（次章参照）

ポイント
EBS のサイズ変更はオンラインで実施可能です。インスタンスを停止する必要がなく、CI パイプラインの稼働時間に影響しません。

ファイルシステム拡張とマウントポイント設定

1. デバイス名を確認（例：/dev/nvme1n1）

bash
lsblk

1. ファイルシステムのリサイズ

2. ext4 の場合

   bash
sudo resize2fs /dev/nvme1n1
   - xfs の場合（デフォルトで XFS が推奨）

   bash
sudo xfs_growfs /dev/nvme1n1

3. 新しいマウントポイント作成（Jenkins 用例）

bash
sudo mkdir -p /var/lib/jenkins_tmp
sudo chown jenkins:jenkins /var/lib/jenkins_tmp

1. fstab に永続化エントリを追加

bash
echo "/dev/nvme1n1 /var/lib/jenkins_tmp ext4 defaults,noatime 0 2" | sudo tee -a /etc/fstab

1. マウント実行と確認

bash
sudo mount -a
df -h /var/lib/jenkins_tmp
# 例: 30G 0 30G 0% /var/lib/jenkins_tmp

このディレクトリを Jenkins の一時領域として利用すれば、RAM の制約から完全に解放されます。

Jenkins エージェントの一時領域切替え実装方法

代替ディレクトリを用意したら、Jenkins 本体とエージェントがその場所を使用するよう設定します。ここでは 環境変数 TMPDIR の設定 と systemd ユニットオーバーライド、そして UI からの個別ノード設定 の３パターンを示します。

TMPDIR 環境変数による全体切替

Linux の多くのツールは TMPDIR を参照して一時ファイルを書き込みます。Jenkins サービスにこの変数を設定すれば、ビルドスクリプトや内部プロセスが自動的に新しいパスを使用します。

1. サービス用環境ファイルへ追記（Amazon Linux 系は /etc/sysconfig/jenkins）

bash
sudo tee -a /etc/sysconfig/jenkins <<'EOF'
export TMPDIR=/var/lib/jenkins_tmp
EOF

1. Jenkins サービスを再起動（エージェントも同様に再起動が必要）

bash
sudo systemctl restart jenkins

1. 設定が反映されたか確認

bash
sudo cat /proc/$(pgrep -f jenkins)/environ | tr '\0' '\n' | grep ^TMPDIR=
# 出力例: TMPDIR=/var/lib/jenkins_tmp

影響範囲
systemctl restart jenkins はマスターノードだけでなく、Jenkins エージェントが systemd 管理下にある場合 も同様に再起動が必要です。エージェントを手動（Java -jar）で起動しているケースは、プロセス停止 → 再起動 が不可欠です。

systemd ユニットオーバーライドで永続化

/etc/sysconfig/jenkins が存在しない環境や、ユニットファイルだけで完結させたい場合は systemctl edit を使います。

1. オーバーライド作成

bash
sudo systemctl edit jenkins

1. エディタに以下を入力して保存

[Service]
Environment="TMPDIR=/var/lib/jenkins_tmp"

1. デーモン再読込とサービス再起動

bash
sudo systemctl daemon-reload
sudo systemctl restart jenkins

この方法は 永続的かつ他のパッケージアップデートに上書きされにくい という利点があります。

Jenkins UI からノード単位で設定変更

Jenkins の管理画面でも一時ディレクトリを個別に指定できます。特にエージェントが Docker コンテナや Kubernetes Pod 上で動作している場合は、UI 設定だけで切り替えられる点が便利です。

1. 管理者権限で Jenkins にログイン
2. Manage Jenkins → Manage Nodes → 対象ノード → Configure を選択
3. 「Temporary directory」欄に /var/lib/jenkins_tmp（または任意パス）を入力し 保存

注意点
UI で設定した場合でも、エージェントプロセスが再起動されるまで新しいディレクトリは使用されません。ノードの「再接続」や手動でのエージェント再起動を忘れずに行ってください。

運用・監視と対策後の検証フロー

設定変更が完了したら、定期的なクリーンアップ と モニタリング、そして ビルド正常性テスト を組み合わせて運用を安定させます。

定期的な /tmp（または代替ディレクトリ）クリーンアップ

一時領域に残ったファイルが蓄積すると、再び容量不足になる恐れがあります。cron ジョブで自動削除する例を示します。

設定手順

CloudWatch カスタムメトリクスで使用率監視

AWS 環境では CloudWatch Agent を用いてディスク使用率を取得し、閾値超過時に SNS 通知を送ります。

1. エージェント設定（/opt/aws/amazon-cloudwatch-agent/etc/agent-config.json）

json
{
"metrics": {
"append_dimensions": { "InstanceId":"${aws:InstanceId}" },
"metrics_collected": {
"disk": {
"measurement": ["used_percent"],
"resources": ["/var/lib/jenkins_tmp"],
"ignore_file_system_types": ["tmpfs"]
}
}
}
}

1. エージェント起動と送信確認

bash
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/agent-config.json -s

1. アラーム作成（閾値 80 %）

bash
aws cloudwatch put-metric-alarm \
--alarm-name JenkinsTmpDiskUsageHigh \
--metric-name used_percent \
--namespace CWAgent \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--dimensions Name=InstanceId,Value=$(curl -s http://169.254.169.254/latest/meta-data/instance-id) \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:OpsAlert

ビルド正常性テストと結果確認

設定後は実際に Jenkins ジョブを走らせ、/tmp 関連エラーが出ないことを検証します。

• 期待結果：dd がエラーなく完了し、ジョブが SUCCESS になる
• 失敗時の対処：df -h $TMPDIR と mount | grep $TMPDIR を確認し、サイズやマウントオプションに誤りが無いか再チェック

この一連のフロー（クリーンアップ → 監視 → テスト）を定期的に実施することで、/tmp 容量不足による Jenkins 障害の再発防止 が可能になります。

まとめ

• Amazon Linux 2023 のデフォルト /tmp は tmpfs（サイズ＝RAM の約 50 %）でマウントされ、Jenkins の大容量ビルドに脆弱
• df -h と mount で現状を把握し、systemd tmpfiles.d または /etc/fstab でサイズ上限を拡張できることを確認
• 永続的かつ大容量が必要な場合は EBS ボリュームを追加・リサイズ → 新規マウントポイント /var/lib/jenkins_tmp を作成し、Jenkins の一時領域として利用するのが最も安全
• 変更後は Jenkins サービスと全エージェントの再起動 が必須である点に注意
• 定期的なクリーンアップ、CloudWatch による使用率監視、そしてビルドテストを組み合わせた運用フローを導入すれば、CI 環境の安定稼働が実現できる

以上で Amazon Linux 2023 上の Jenkins における /tmp 容量不足対策 の全手順とベストプラクティスをご紹介しました。実装後は必ずテスト・監視を行い、問題が再発しないことを確認してください。