TomcatとRPM：消失を再現できなかった調査

このページの使い方

当時の判断を思い出すことを入口に、今の自分の知識を更新する。思い出せない事実はunknownのまま、必要な仕組みを学び直してよい。 対話はChatGPT、編集と同期はCodexで行う。ケース一覧から別のケースも選べる。

2026-09-14、Issue #16としてObsidianの Untitled. 2 から整理した初稿。元ノートの要約であり、全ログ・コードの独立確認や今回の再実験ではない。実際の学習sessionはまだない。原文の観測と解釈、AIによる補足を分ける。

ChatGPTで振り返り、知識を更新する

ChatGPT開始文

https://github.com/MFQWKMR4/tech2026 を参照してください。
AGENTS.md、CHATGPT.md、src/content/docs/career/index.md、
src/content/docs/projects/tomcat-rpm-investigation.md、reviews/experience-tomcat-rpm.yaml、
.github/ISSUE_TEMPLATE/session-sync.mdと、reviewが参照する必要なsessionを読んでください。
読めたファイルとcommit SHAを示し、読めなければ読んだとせずsession packを求めてください。
今回はsession_type: experience、topic: experience-tomcat-rpmです。
当時の状況・担当・判断を一問ずつ聞いて回答を待ち、記憶を埋めるだけで終えず、必要な仕組みを学び直す時間も取ってください。
最初は「RPM更新が削除したという説明を受けたとき、最初にどんな仮説を立てましたか？」と聞いてください。
元ノートの記載、当時の解釈、今回の記憶、自力の説明、AIの補足、今なら考える案を区別してください。
過去の結論を正解と固定せず、必要な箇所で一次資料と対象バージョンを確認し、日本語で説明してください。
不明な用語や前提を一つずつ説明し、理由・trade-off・例外・運用・切り分けへつないでください。
説明後は条件を少し変えた短い問いで現在の理解を確認し、解説後の回答であることを記録してください。
変更条件は「演習上の追加条件」と明示し、当時の事実へ混ぜないでください。
記憶を深掘りできない場合や私が仕組みを知りたい場合は、過去の確認に留まらず今の疑問へ進んでください。
技術の説明だけから過去の担当能力・実績を評価せず、経験の確認と現在の理解をsummaryでも分けてください。
全節や全質問を一回で消化せず、一つの仕組みを深めてください。模範の経験談を先に作らないでください。
思い出せない実務事実はunknownのまま残し、未質問を不足や忘却と判定しないでください。
会社名・顧客名・識別情報・非公開の社内情報は記録しないでください。
開始時刻を確認できれば記録し、40分付近で区切りを提案。時刻不明なら推測しないでください。
終了時は実際の問い・回答・ヒント・理解の変化・未確認事項をYAML＋Session narrativeへまとめ、
MFQWKMR4/tech2026に[Session Sync] Issueを作り、URLを返してください。
repository_requestsには、このページへ戻す経緯・新しい技術解説・再確認したい問いを記載してください。
元ノートや教材作成を私の学習evidenceにせず、今回の回答を根拠にしてください。
Issue作成機能が使えなければ未作成と明示し、コピーできるタイトルと本文を返してください。

【求人との接点を意識した深掘り】
以下は2026-09-14に私が提示した求人の観点です。求人の最新性や、私が要件を満たすことを確認済みとは扱わないでください。
必須：バックエンドWebアプリ開発、REST APIの設計・実装、チームでの技術検討と開発、クラウド／サーバー基盤の基礎知識。
歓迎：高頻度・高負荷アクセスへのスケーラブルな設計・開発・運用、RDBMS／KVSの利用・最適化・運用、LB／CDNによる高可用性、HTTP/HTTPSの仕様理解。
歓迎：AWS／Google Cloudの構築・開発、ECS(Fargate)／Cloud Run等のコンテナ運用、ALB・Lambda・SQS・DynamoDB等を組み合わせる設計。
歓迎：長期運用と機能拡張を見据えた保守性、テスト・CI/CD、DDD、認証・認可・セキュリティ、OIDC／OAuth 2.0、TLS・暗号・署名検証。
歓迎：ゲーム専用機／IoT機器向けAPI、WebRTC、分散システムの開発。
人物像：課題の本質を追い最後まで取り組む、長期運用を考え抜く、新技術を楽しみ挑戦する、クライアント／企画まで視野を広げる、複雑な課題を正しく言語化し周囲を尊重して協働する、利用者視点でチームと課題を解く。

既存needs_revisitを優先しつつ、このケースと回答に関係する観点を1〜2個選び、一問ずつ掘り下げてください。全項目をチェックリストのように消化しないでください。
「どの課題・利用者影響があったか → 自分の担当・行動 → 判断の理由と代案 → チーム内の検討・合意 → 検証・運用結果 → 今なら変えること」を、回答に応じて確認してください。
私が実施した設計・実装、運用・調査、現在理解している知識、未経験／未確認を分けてください。規模・期間・成果の数値は回答に根拠がある場合だけ使ってください。
技術名が登場しただけで経験ありとせず、求人項目を自動でgap・needs_revisit・学習evidenceにしないでください。歓迎要件をすべて経験している前提で質問しないでください。
当時の情報が足りなければunknownを残し、今知りたい仕組みは一次資料で補足して理解を更新してください。解説後の回答を当時の能力へ書き換えないでください。
実際の回答が集まったら、まず私自身に面接で話す短い説明を試してもらい、その後で根拠のある経験と求人との接点、追加確認が必要な点を整理してください。合否や数値スコアは付けないでください。
Session Syncのsummaryとnarrativeには、扱った求人観点と回答根拠、当時の経験／今の学びの区別を残してください。repository_requestsにはページへ戻す補足を記載してください。
このケースで優先する候補：保守性、テスト／リリースの安全性、運用時の変更管理、未再現を正しく伝える協働。更新調査をCI/CD基盤の構築経験と同一視しないでください。

GitHubを読めない場合はCodexで npm run session:pack -- experience-tomcat-rpm を実行し、出力を渡す。ChatGPTがローカルVaultを読めることは前提にしない。

本人の経験：元ノートにあること

問題と調査の経緯

AL2023でTomcat 9.0.117から9.0.120へ更新した際、webapps配下のWARと展開済みアプリが消えたという報告を調査した。ノートの結論は本人の検証環境では消失を再現できず、追加の構成確認が必要というもの。

段階	ノートの観測・行動	言えたこと・残る確認
パッケージを比較	更新前後のRPMを取得し、scriptlet、file trigger、ファイル所有を確認	調べた範囲にwebappsを削除する処理を見つけなかった。他パッケージや別の実行主体まで除外したわけではない
条件を変えて再現	停止中、稼働中、OS全体更新の条件でテスト	いずれもアプリ消失は再現せず。稼働時にundeployと再デプロイを観測した
timestampを切り分け	削除がなくてもディレクトリのctime更新を観測	時刻の一致を削除の証拠にできないと確認した
一つずつ変更	appBaseのmtime変更では再デプロイせず、context.xmlのmtime変更では再デプロイした	この検証条件での再デプロイの引き金を分離。報告されたWAR消失と同じ現象だとは確定しない
回答と次の調査	結果を整理し、Host設定・配置形態・journal・更新履歴などを依頼する方針	ノート時点は初回回答。最終原因・追加資料・後続の修正はunknown

ノートに残る判断の変化

「RPMが直接消したか」から、パッケージ更新が別プロセスの動作を誘発した可能性へ視野を広げた。一方で、再デプロイが起きたことをアプリ消失の再現成功とは扱っていない。この二つを分けて回答した経緯を深掘りする。

AIによる技術補足：今の理解を更新する

Default / Why：更新はファイル配置だけではない

RPMの更新では新旧パッケージのscriptletやtriggerが関与する。更新後の rpm -q --scripts だけでは、削除される旧版の処理を確認したことにならない。旧・新版の実ファイルを対象に比較し、他のパッケージのtriggerも視野に入れる。RPM 4.20 triggerの順序。

「RPMは所有しないファイルを絶対に削除しない」という原文の一般化は避ける。通常の所有ファイル管理と、任意の処理を行い得るscriptlet/triggerを分ける。パッケージの所有一覧だけでは、更新が間接的に削除を誘発しなかった証明にならない。

timestampから削除主体は分からない

ctimeはinodeの状態変更時刻で、作成時刻や削除専用の時刻ではない。所有者・権限などの変更でも更新される。mtime、inode、更新前後の一覧、実行主体のログを照合する。原文の「BirthからAMIを推定」は仮説の入口にはなっても、AMIや作成履歴を一意に識別する根拠ではない。inode(7)。

Trade-off / Exception：自動デプロイの便利さと予期しない変更

Tomcatの自動デプロイはWAR・展開DIR・XML・global resourceの変更を扱う。削除・再生成は資源の種類と設定に依存する。context.xmlで再デプロイしたという観測から、元のWAR削除まで断定しない。global resource等の例外もあり、表の対象条件を確認する。Tomcat自動デプロイ（確認時9.0.121）。

今なら、更新前にサービスを停止する案、自動デプロイを抑えて明示的に切り替える案、OS更新とアプリ配置を分離する案を比較する。停止時間、ロールバック、稼働中の変更検出をどう管理するかまで考える。単にautoDeployを無効にすれば配置運用が完成するわけではない。

Production / Troubleshooting：再現しない結果を次の観測へ

再現条件の表に、期待した消失、観測した再デプロイ、残存したファイルを別列で残す。次は対象プロセス・ファイルへの操作を捕捉できる計測を検討し、時間帯と対象パスを絞る。ログ収集自体の負荷や情報量も設計する。リリース・ロールバックへ接続できる。

次の対話：当時から今へ

• 当時：再現しなかったとき、どの時点で追加ヒアリングに進む判断をしたか。
• 仕組み：ファイルの所有者、変更時刻、操作したプロセスをどう区別するか。
• 今なら：同じ再現試験を何度も繰り返す前に、何を観測すれば候補を減らせるか。
• 設計判断：OSパッチ適用とアプリのデプロイを独立させるなら、何を変えるか。

経験の核は、報告を否定せず、検証できたことと未再現を正確に伝えること。再デプロイの発見を消失原因の確定へ置き換えない。

出典・対象環境

元ノート：AL2023、Tomcat 9.0.117→9.0.120。RPMの厳密な版・release番号は未収録。一次資料は2026-09-14確認、RPM 4.20の説明、Tomcat 9.0.121の公式文書、inode(7)のWeb版。今回の環境で更新や削除の再現試験は実施していない。

セッションと次の更新

元資料の参照は2026-09-14。原文は変更せず、顧客情報・内部情報を転載していない。本人の独力回答や深掘りsessionは未登録。質問候補と補足は学習済みの証拠ではない。ChatGPTのSession Sync後に、当時の経緯と今の理解の変化を区別して追記する。