Linux OS の EC2 インスタンスで静的ホスト名が意図せず戻る場合の調査ポイントを考えてみた
はじめに
テクニカルサポートの 片方 です。
EC2 の Linux OS インスタンスで静的ホスト名を設定したにもかかわらず、再起動後にホスト名が元に戻ってしまう事象について、お問い合わせをいただくことがあります。
このような事象では、まず hostnamectl や cloud-init の設定に注目しがちですが、実際には cloud-init 以外の仕組みがホスト名を変更している場合もあります。
そのため、設定ファイルの確認だけでは原因を特定できず、ログやサービス定義、起動シーケンスまで含めて切り分ける必要があります。
本記事では、EC2 の Linux OS インスタンスにおいて、静的ホスト名が意図せず戻る場合の調査ポイントを整理して紹介します。
当社サポート窓口で蓄積したナレッジをもとに、設定確認からログ調査、systemd ユニットの確認、auditd を用いた再発時の追跡方法まで、汎用的な調査の進め方としてまとめました。
まず押さえたい前提
EC2 の Linux OS インスタンスでホスト名が元に戻る場合、最初に理解しておきたいのは、ホスト名を変更する要素が cloud-init だけではないということです。
静的ホスト名の設定では、hostnamectl と cloud-init の preserve_hostname を組み合わせる構成がよく用いられます。
一方で、実際の運用環境では、systemd サービス、ユーザーデータ、独自スクリプト、構成管理ツール、サードパーティー製ソフトウェアなどがホスト名を変更することもあります。
そのため、ホスト名が戻る事象では、単に cloud.cfg の設定内容だけを見るのではなく、ログや起動時の処理、関連サービスの有無まで含めて切り分けることが重要です。
また、systemd-hostnamed のログは「変更が行われたこと」を示していても、「誰が変更を指示したか」を直接示しているとは限らない点にも注意が必要です。
代表的な原因候補
EC2 の Linux OS インスタンスで静的ホスト名が意図せず戻る場合、原因は 1 つとは限りません。
hostnamectl や cloud-init の設定が正しく見えていても、OS 起動時の別処理や追加導入されたソフトウェアによってホスト名が上書きされることがあります。
ここでは、調査時に確認したい主な原因候補を紹介します。
- cloud-init によるホスト名の設定
EC2 の初期設定では、cloud-init がホスト名の設定に関与することがあります。
特に preserve_hostname が未設定、または false の場合は、起動時に EC2 のメタデータに基づくホスト名へ更新される可能性があります。
このため、まずは以下の観点を確認します。
- /etc/cloud/cloud.cfg や /etc/cloud/cloud.cfg.d/ 配下で preserve_hostname: true が設定されているか
- cloud-init のログにホスト名更新の記録がないか
- 設定ファイルが想定どおりに読み込まれているか
- /etc/hostname や関連ファイルの上書き
静的ホスト名は通常 /etc/hostname に保持されますが、何らかの処理によってこのファイルが更新されると、再起動後のホスト名も変わる可能性があります。
あわせて、環境によっては /etc/hosts や /etc/sysconfig/network などの内容が影響することもあります。
このため、以下の点を確認します。
- /etc/hostname の内容が意図した値になっているか
- 再起動後にファイル内容が変更されていないか
- 設定ファイルを更新する独自スクリプトや構成管理の仕組みがないか
- systemd サービスや起動スクリプトによる変更
ホスト名は cloud-init 以外にも、OS 起動時に実行される systemd サービスや独自スクリプトによって変更されることがあります。
たとえば、起動後に IMDS からホスト名を取得し、hostnamectl set-hostname を実行するサービスが存在すると、preserve_hostname を設定していてもホスト名が上書きされます。
このようなケースでは、以下のような要因が考えられます。
- 独自作成した systemd ユニット
- AMI 作成時から組み込まれている起動スクリプト
- ユーザーデータで実行される設定処理
- ミドルウェアやエージェントのインストールに伴って追加されたサービス
-
systemd-hostnamed を経由した別プロセスからの変更
ログを確認すると、systemd-hostnamed がホスト名を変更したように見える場合があります。
ただし、これは必ずしも systemd-hostnamed 自体が原因であることを意味しません。
実際には、別のプロセスやサービスが hostnamectl などを実行し、その結果として systemd-hostnamed がホスト名変更を処理していることがあります。
そのため、systemd-hostnamed のログが見つかった場合は、その直前後にどのサービスやプロセスが動作していたかを確認することが重要です。 -
構成管理ツールやサードパーティー製ソフトウェア
運用環境では、Ansible、Chef、Puppet などの構成管理ツールや、ログ転送、監視、セキュリティ対策のためのエージェントが導入されていることがあります。
これらが OS の初期化処理や起動後処理の一部としてホスト名を再設定しているケースも考えられます。
特に以下のような場合は注意が必要です。
- 再起動のたびに同じタイミングでホスト名が戻る
- 追加ソフトウェアの導入後から事象が発生している
- 同じ AMI から起動した複数台で同様の事象が起きている
- 特定サービスの起動後にホスト名が変更される
- 手動操作や運用手順の影響
意図しないホスト名変更は、必ずしも自動処理だけが原因とは限りません。
メンテナンス作業時に実行したスクリプトや、運用手順の中で呼び出された設定コマンドが影響している可能性もあります。
たとえば、以下のようなケースです。
- 作業用スクリプトの中で hostnamectl set-hostname を実行している
- 再起動前後に別担当者が設定変更を行っている
- スナップショット取得や AMI 作成前後の手順に hostname 設定処理が含まれている
そのため、ログ調査とあわせて、事象発生前後に実施された作業履歴や変更履歴も確認すると切り分けに役立ちます。
- ブート時の一時的な表示と恒久的な変更の混同
再起動直後のログでは、一時的に localhost や別のホスト名が設定されたように見える場合があります。
これはブートシーケンスの途中で一時的に設定されているだけであり、最終的な恒久設定の上書きとは別の挙動であることがあります。
そのため、以下を区別して確認することが重要です。
- ブート途中の一時的なホスト名設定
- 再起動完了後に維持される静的ホスト名
- その後さらに別サービスによって上書きされた変更
単一のログだけで異常と判断せず、前後の時系列を通して確認することが大切です。
- 複数要因が重なっているケース
実際の障害調査では、原因が 1 つだけとは限りません。
たとえば、cloud-init はホスト名を変更していない一方で、起動後に別サービスが IMDS から取得した値で上書きしている、といった複合的なケースもあります。
そのため、調査時は最初から 1 つの要因に決め打ちせず、以下のように段階的に切り分けることが重要です。
- cloud-init の設定とログを確認する
- システムログから変更時刻を特定する
- その時刻に動作したサービスやスクリプトを確認する
- 必要に応じて監査ログで変更元プロセスを特定する
このように、静的ホスト名が戻る事象では、cloud-init だけでなく、設定ファイル、起動サービス、周辺ソフトウェア、運用手順まで含めて幅広く確認することが重要です。
切り分け手順
EC2 の Linux OS インスタンスで静的ホスト名が意図せず戻る場合は、最初に cloud-init を確認し、その後にログと起動サービスを確認する流れで進めると整理しやすくなります。
現在の設定を確認する
まずは、現在のホスト名と永続設定の内容を確認します。
hostnamectl
hostname
cat /etc/hostname
cat /etc/hosts
ディストリビューションや AMI によっては、補助的に以下も確認します。
cat /etc/sysconfig/network
ここでは、hostnamectl の表示と /etc/hostname の内容が一致しているか、意図しないホスト名が保存されていないかを確認します。静的ホスト名は、通常 /etc/hostname に保存される値として扱われます。
コマンド実行例
sh-5.2$ hostnamectl
hostname
cat /etc/hostname
cat /etc/hosts
Static hostname: ip-10-0-21-28.ap-northeast-1.compute.internal
Icon name: computer-vm
Chassis: vm 🖴
Machine ID: ec252d11ff2c23dd0eb2e38b25a3109e
Boot ID: 0838610cc8dc4d9fa1292997db76804e
Virtualization: amazon
Operating System: Amazon Linux 2023.10.20260325
CPE OS Name: cpe:2.3:o:amazon:amazon_linux:2023
Kernel: Linux 6.1.164-196.303.amzn2023.x86_64
Architecture: x86-64
Hardware Vendor: Amazon EC2
Hardware Model: t3.micro
Firmware Version: 1.0
ip-10-0-21-28.ap-northeast-1.compute.internal
ip-10-0-21-28.ap-northeast-1.compute.internal
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost6 localhost6.localdomain6
sh-5.2$ cat /etc/sysconfig/network
NETWORKING=yes
NOZEROCONF=yes
sh-5.2$
cloud-init の設定を確認する
次に、cloud-init がホスト名を上書きしない設定になっているかを確認します。
grep -n preserve_hostname /etc/cloud/cloud.cfg
grep -R preserve_hostname /etc/cloud/cloud.cfg.d/
ls -al /etc/cloud/cloud.cfg
ls -al /etc/cloud/cloud.cfg.d/
preserve_hostname: true が設定されていない場合、起動時にホスト名が更新される可能性があります。AWS re:Post でも、静的ホスト名を維持する前提としてこの設定が案内されています。
なお、Amazon Linux 2023 では、cloud-init は /etc/cloud/cloud.cfg.d と /etc/cloud/cloud.cfg の設定を利用し、/etc/cloud/cloud.cfg.d 配下のファイルは辞書順に読み込まれ、後のファイルが前の値を上書きします。
cloud-init のログを確認する
設定を確認したら、実際に cloud-init がホスト名変更処理を行ったかをログで確認します。
grep -E "set_hostname|update_hostname|preserve_hostname|hostname" /var/log/cloud-init.log
grep -i hostname /var/log/cloud-init-output.log
cloud-init の現行ドキュメントでは、preserve_hostname: true の場合、Update Hostname モジュールはシステムホスト名を変更しないと説明されています。また、preserve_hostname を指定しない場合の既定動作は preserve_hostname: false 相当です。そのため、preserve_hostname: true が設定され、ログ上でもホスト名更新をスキップしていることが確認できる場合は、cloud-init 以外の要因を疑う材料になります。
This module will update the system hostname and FQDN. If preserve_hostname is set to true, then the hostname will not be altered.
Config schema
preserve_hostname: (boolean) If true, the hostname will not be changed. Default: false.
When preserve_hostname is not specified, cloud-init updates /etc/hostname per-boot based on the cloud-provided local-hostname setting. If you manually change /etc/hostname after boot, cloud-init will no longer modify it.
確認時のポイントは以下のとおりです。
- set_hostname や update_hostname に関するログが出力されているか
- preserve_hostname が設定されているため、ホスト名を変更しない旨のログがあるか
- ホスト名変更が発生した時刻と cloud-init の処理時刻が一致しているか
システムログから変更時刻を特定する
次に、いつホスト名が変わったのかをログから特定します。
Amazon Linux 2023 では systemd-journal が標準のため、まず journalctl を使って確認します。AL2023 では rsyslog がデフォルトではインストールされず、/var/log/messages のようなテキストログファイルは通常存在しません。
journalctl | grep -i hostnam
journalctl --since "2026-02-17 19:50:00" --until "2026-02-17 20:10:00" | grep -i hostnam
journalctl は systemd journal のログを表示するコマンドで、--since や --until による時刻指定が利用できます。
rsyslog などでテキストログを出力している環境では、/var/log/messages を直接確認します。
また、時刻をある程度絞りたい場合は、以下のように確認します。
grep -i hostnam /var/log/messages
grep "Feb 17 20:03" /var/log/messages | grep -i hostnam
systemd-hostnamed のログが見つかることがあります。systemd-hostnamed は、ユーザープログラムからホスト名や関連メタデータを制御するためのサービスで、hostnamectl はそのクライアントの 1 つです。そのため、systemd-hostnamed のログがあっても、hostnamectl など別のクライアントやサービスが変更要求を出している可能性があります。
確認時のポイントは以下のとおりです。
- systemd-hostnamed によるホスト名変更の記録があるか
- 変更前後でどのホスト名に変化したか
- 再起動、サービス起動、スクリプト実行などのイベントと時刻が近接していないか
起動サービスやユーザーデータを確認する
cloud-init でなければ、起動時に動く別の処理がホスト名を変更している可能性があります。systemd サービスやユーザーデータ、構成管理ツールを確認します。EC2 のユーザーデータでは、Linux インスタンスに対してシェルスクリプトや cloud-init ディレクティブを渡して起動時処理を実行できます。
Amazon EC2 インスタンスの起動時に、インスタンスの起動後に自動設定タスクを実行したり、スクリプトを実行したりするのに使用するインスタンスにユーザーデータを渡すことができます。
systemctl list-unit-files | grep -i host
systemctl list-units --type=service | grep -i host
systemctl cat <service-name>
systemctl status <service-name> -l --no-pager
特に、以下のような処理がないかを確認します。
- hostnamectl set-hostname を実行しているサービス
- IMDS からホスト名を取得して設定するスクリプト
- ユーザーデータや独自運用スクリプトによる /etc/hostname の上書き
原因が分からない場合は auditd で監視する
ここまでの設定確認やログ確認だけで原因を特定できない場合は、事象再発時の証跡を取得できるよう、あらかじめ auditd を設定しておく方法が有効です。
この手順の主目的は、今この場で手動テストの成功例を取得することではなく、再発時に「どのプロセスが」「いつ」「どのように」ホスト名を変更したのかを追跡できるようにすることです。
具体的には、以下の 2 つを監視します。
- sethostname システムコール
- /etc/hostname の更新
sethostname(2) は、Linux カーネルのホスト名を設定するシステムコールです。
sethostname() sets the hostname to the value given in the character array name. The len argument specifies the number of bytes in name. (Thus, name does not require a terminating null byte.)
- audit パッケージのインストールと起動
audit パッケージがインストールされていない環境では、事前にインストールとサービス起動を行います。
sudo dnf install -y audit
sudo systemctl enable --now auditd
- 監査ルールの設定
続いて、ホスト名変更を監視するルールを設定します。
sudo -i
mkdir -p /etc/audit/rules.d
cat >/etc/audit/rules.d/hostname.rules <<'EOF'
-a always,exit -F arch=b64 -S sethostname -k hostname_change
-a always,exit -F arch=b32 -S sethostname -k hostname_change
-w /etc/hostname -p wa -k hostname_file_change
EOF
- 監査ルールの反映と確認
設定したルールを反映し、カーネルにロードされていることを確認します。
augenrules --load
auditctl -l | grep hostname
augenrules --load 実行時に Old style watch rules are slower と表示される場合がありますが、auditctl -l で対象ルールが表示されていれば、監査ルールは反映されています。
- 事象再発時の確認
事象が再発した際は、以下のコマンドで確認します。
sudo ausearch -k hostname_change -i
sudo ausearch -k hostname_file_change -i
この確認では、主に以下の点を見ます。
- どの実行ファイルが sethostname を呼び出したか
- 実行ユーザーが誰か
- どの時刻に、どのプロセスが変更を行ったか
- /etc/hostname 自体が書き換えられていないか
特に sudo ausearch -k hostname_change -i の結果では、type=SYSCALL、exe=...、comm=...、pid=... などを確認することで、変更元のプロセスを特定しやすくなります。
事前に動作確認したい場合
上記の手順の主目的は再発時調査のための事前準備ですが、監査ルールが正しく動作しているか不安な場合は、事前にテストを行うこともできます。
たとえば、テスト用にホスト名を変更し、直近のイベントに絞って確認すると分かりやすくなります。
sudo hostnamectl set-hostname test-hostname
sudo ausearch -ts recent -k hostname_change -i
sudo ausearch -ts recent -k hostname_file_change -i
/etc/hostname の監視を確認したい場合は、以下のように直接書き込んで確認することもできます。
sudo sh -c 'echo test-hostname > /etc/hostname'
sudo ausearch -ts recent -k hostname_file_change -i
ausearch の結果にイベントが表示されない場合
ausearch の結果が no matches となる場合、監査ルールはロードされていても、対象イベントが記録されていない可能性があります。
その場合は、まず以下を確認してください。
sudo auditctl -s
sudo systemctl status auditd --no-pager
sudo auditctl -l
また、auditctl -l の出力に以下のようなルールが含まれている場合があります。
-a never,task
このルールが存在する環境では、新規プロセスに対する監査ルール処理が期待どおりに行われず、sethostname や /etc/hostname の変更イベントが取得できないことがあります。
そのため、ausearch に期待したイベントが記録されない場合は、never,task ルールの有無もあわせて確認してください。
無効化方法
never,task が有効になっている場合は、永続設定から無効化します。
auditctl(8) では、10-no-audit.rules を削除し、代わりに 10-base-config.rules を audit rules directory に追加するよう案内されています。
sudo rm -f /etc/audit/rules.d/10-no-audit.rules
sudo cp /usr/share/audit/sample-rules/10-base-config.rules /etc/audit/rules.d/
sudo augenrules --load
sudo auditctl -l
augenrules は /etc/audit/rules.d 配下の .rules ファイルをマージして /etc/audit/audit.rules を生成し、--load でカーネルへロードします。 .rules 以外のファイルは処理されません。
それでも -a never,task が残っている場合は、カーネルにロード済みの古いルールが残っている可能性があるため、いったん現在のルールを削除してから再ロードします。auditctl -D は、すべての rules と watches を削除するオプションです。
sudo auditctl -D
sudo augenrules --load
sudo auditctl -l
この時点で sudo auditctl -l | grep never,task を実行し、何も表示されないことを確認してください。
その後、再度ホスト名変更を試し、ausearch でイベントが取得できるか確認します。
sudo hostnamectl set-hostname test-hostname
sudo ausearch -ts recent -k hostname_change -i
sudo ausearch -ts recent -k hostname_file_change -i
補足
ausearch の結果として CONFIG_CHANGE のみが表示される場合がありますが、これは監査ルールの追加や削除を記録したものであり、ホスト名変更そのものを示すものではありません。
ホスト名変更の調査では、SYSCALL や PATH を含むイベントが取得できているかを確認することが重要です。
このような手順により、通常のシステムログだけでは特定が難しい場合でも、ホスト名変更を実行したプロセスやサービスを追跡できる可能性があります。
実際に、この方法で再発時の状況を調査した結果、サードパーティー製ソフトウェアに関連する systemd サービスがホスト名を上書きしていた事例もありました。
時系列で整理する
最後に、調査結果は時系列で整理するのがおすすめです。
- ホスト名を設定した時刻
- cloud.cfg を編集した時刻
- インスタンスを再起動した時刻
- ホスト名が戻った時刻
- その前後で起動したサービスや実行されたスクリプト
単一のログだけで判断せず、「いつ」「誰が」「どの方法で」変更したかを並べてみると、原因を絞り込みやすくなります。
まとめ
EC2 の Linux OS インスタンスで静的ホスト名が意図せず戻る場合、まず cloud-init の設定を疑うことが多いですが、実際にはそれ以外の要因でホスト名が変更されることもあります。
そのため、hostnamectl や preserve_hostname の設定確認だけで調査を終えず、ログや起動サービス、必要に応じて監査ログまで含めて切り分けることが重要です。
今回ご紹介した調査の流れは、以下のとおりです。
- 現在のホスト名と関連設定ファイルを確認する
- cloud-init の設定とログを確認する
- システムログからホスト名が変更された時刻を特定する
- systemd サービスやユーザーデータ、構成管理ツールの影響を確認する
- 原因が特定できない場合は auditd で変更元プロセスを監視する
特に、ログに systemd-hostnamed が記録されていても、それだけで原因を断定できるとは限りません。
どのサービスやプロセスがホスト名変更を要求したのか、時系列で整理しながら確認することが原因特定への近道になります。
同様の事象が発生した際は、本記事の手順をもとに、設定、ログ、関連サービスの順で確認を進めてみてください。
本ブログが、EC2 の Linux OS インスタンスにおけるホスト名変更事象の調査に役立てば幸いです。
参考資料
- EC2 Linux インスタンスに静的ホスト名を割り当てる | AWS re:Post
- Module reference - cloud-init 24.3 documentation
- Update hostname and FQDN - cloud-init 26.1 documentation
- systemd-hostnamed.service
- ユーザーデータ入力を使用して EC2 インスタンスを起動するときにコマンドを実行する - Amazon Elastic Compute Cloud
- sethostname(2): get/set hostname - Linux man page
- auditctl(8) - Linux manual page
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
