はじめに
Oracle Cloud Infrastructure (OCI) の Always Free VMで勉強用サーバーを動かしていたところ、プロンプトが動かなくなり何を入力しても反応しなくなった。
しかも、こういうことが初めてではなくそのたびに勉強を中断していた
- その日の最初はSSH接続はできる
- 調べ物をしながら触っているといつの間にか反応しなくなる(だいたい1時間くらい？)
- 数時間放置して戻ってくるとまた動く
- 切断して別日にもう一度接続すると動く
という現象
さすがに勉強が続かないので今回は、詳しく調査して原因を突き止めることにした
やったこと
- Linuxログ調査
- いくつかのサービスの停止
現在、LinuC Lv1-102(Ver10.0)試験の勉強中であるが、
今回の一連の調査は試験勉強としての知識の習得よりも、実務で障害が起きたときの対応練習として意義深い学びだと感じている。
そこで、記事としてまとめることにした
OCI環境について
OCI上で作成しているVMは下記の構成になっている
ユーザー：私用PC
│
SSH接続
│
Internet Gateway：OCIのクラウド上に作成済み
│
VCN：OCIのクラウド上に作成済み
│
**Compute Instance**：ここにCPU、メモリ、ストレージなどリソースが割り当てられている
このCompute InstanceでImageにはOracle-Linux-9.7-2026.04.30-3を使用しているが、これがCentOSやUbuntuなどのいわゆるLinux OSとほとんど同じものになっている。
ところが、今回の調査でOracle-Linux-9.7-2026.04.30-3には、OCI独自のサービスとして
Oracle Cloud Agent
という管理用エージェントが動いていることがわかった。
無料枠のクラウド利用で小さいリソースしか割り当てられていないのに、Linuxとしての最低限の機能だけでなく
OCI独自サービスがCPU・メモリをさらに消費している
ことが判明した。
障害対応の基本的な考え方
OCIに限らず、障害対応は下記の流れに沿って対応するらしい
それぞれコマンドと出力結果の読み方を習得する必要があるね
現象の整理
↓
ログ確認
↓
リソース確認
↓
サービス確認
↓
仮説
↓
対策
↓
再確認
この流れが重要。
① ログを残せるようにする
まさかの、デフォルトでは再起動前のログが保存されていなかったため、さっそくつまづくことになった。
$ journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal was found.
$
$ ls -ld /var/log/journal
ls: cannot access '/var/log/journal': No such file or directory
$
「前回起動時のログを保存する場所がない」状態。
最初に原因を調べようとしたときは、ここで調査が止まってしまった。このときは、再起動後にプロンプトが応答するようになり、とりあえず問題なくなった。
定期的に動かなくなる現象が続いていたので、次回同じことが起きたときのために、ログを残せる状態に設定変更する必要があった。
journald使用のためのコマンド
sudomkdir-p /var/log/journal
sudo systemd-tmpfiles--create--prefix /var/log/journal
sudo systemctlrestart systemd-journald
上記3つのコマンドの実行後、
journalctl--disk-usage
で
Archived and active journals take up ...
と表示されればOK
② 起動履歴を見る
journalctl --list-boots
ログが残っていて参照できる起動ログの一覧を出せる
-2
-1
0
と表示された結果、という3回起動した分の履歴をそれぞれ確認できることがわかった
固まった後に再起動した、その前の起動時のログを見たいので、
journalctl -b -1
での結果を見る。
-ｂオプションが起動ログを呼び出す意味。
③ ログ確認
エラーログ調査
さらに絞り込み、
journalctl -b -1 -p err
でエラーログのみを調べると、
auditd[1510]: Email option is specified but /usr/lib/sendmail doesn't seem executable.
systemd[1]: Failed to start Crash recovery kernel arming.
sshd[4749]: error: kex_exchange_identification: Connection closed by remote host
重大エラー(長時間固まった原因)とは思えない。
SSHサービスの調査
SSH接続がうまくいかなかっただけの可能性があったため、
journalctl -b -1 -u sshd
を実行。すると大量の
Invalid user root
Invalid user ubuntu
Invalid user ansible
などが出ていた。これは世界中からのSSH総当たり攻撃であり、公開サーバでは普通のこと。
自分のログイン
Accepted publickey
だけが正常ログとしてのこっており、そこは成功していたためSSHの問題ではない。大量に失敗のログがあったのでこれが原因かと思ったがこれでもないらしい
時間を指定して調査
実際止まっていた時間に何が起きていたかを確認する。
OCIのGUI上で観れるグラフで明らかにメモリ等の使用率が上がっていた時間帯があったのでそこを見る
journalctl -b -k --since "2026-06-27 6:22" --until "2026-06-27 8:00"
を実施。時間指定にくわえ[-k]オプションでさらにログを絞り込んでいる。sshdなどが含まれると大量に出力されてよくわからなかったため。
結果、下記のログを見つけることができた
kernel:Out of memory Killed process dnf
OOM Killer
これはLinuxが
メモリ足りない！
→何か殺すしかない
→dnf終了
という対応をしたということを意味する。
Out of memoryということで、ここからは**何がメモリを圧迫していたか？**の調査に切り替える
④ メモリ使用量確認コマンド
free -h
ps aux --sort=-%mem | head -20
systemd-cgtop
使用コマンドはこの3つ
free -h
出力結果のうち、
total：498MB
available：295Mi
となっていた(だいたい)。OCIの無料枠、Always Free環境なので少なめ？
このうち295Miのavailable部分が「今すぐ使えるメモリ」。これを何かが使い切ってしまうことで動作停止が起きていると予想できる。
ps aux --sort=-%mem | head -20
ps：Process Status
現在動いているプロセスを表示するコマンド
a:全ユーザー
u:User format 見やすい形式で表示する、ということ
例えば
USER
CPU
MEM
START
COMMAND
などが追加される。
x:端末(TTY)を持たないプロセスも表示
例えば
systemd
sshd
NetworkManager
などのサービスも表示される。
-sort=-%mem
--sort=：並び替え
%mem：メモリ使用率
-：使用率の高い者から降順する
systemd-cgtop
topコマンドはプロセス単位であることに対し、systemdサービス単位で見ることができるコマンド
cgはcgroup、Control Groupsのこと。
CPU何%、メモリ何MBを使っているか、をまとめてみることができる
⑤ メモリ使用量確認結果
ps aux --sort=-%mem | head -20結果：
oracle-+ 9727 0.0 4.0 1246908 20852 ? Sl 11:01 0:10 /usr/libexec/oracle-cloud-agent/plugins/oci-wlp/oci-wlp
oracle-+ 9719 0.1 3.8 1241300 19652 ? Sl 11:01 0:18 /usr/libexec/oracle-cloud-agent/plugins/gomon/gomon
ocarun 9749 0.1 3.8 1244776 19472 ? Sl 11:01 0:13 /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand
oracle-+ 9734 0.0 3.1 1241756 16216 ? Ssl 11:01 0:05 /usr/libexec/oracle-cloud-agent/updater/updater
oracle-+ 9679 0.0 2.9 1241744 15176 ? Ssl 11:01 0:07 /usr/libexec/oracle-cloud-agent/agent
pcp 3318 0.0 1.6 25612 8372 ? S 09:59 0:10 /usr/libexec/pcp/bin/pmlogger -N -P -d "/var/oled/pcp/pmlogger/LOCALHOSTNAME" -r -T24h10m -c config.ora -v 100mb -m pmlogger_check %Y%m%d.%H.%M
systemd-cgtop結果：
system.slice 152.5M
user.slice 37.0M
oca.slice 91.4M
このあたり？？
oca.slice：Oracle Cloud Agent全体
system.slice：PCP関連が多数
⑥注目したサービス
PCP：Performance Co-Pilot
Linux性能監視ソフト
役割は
- CPU
- メモリ
- Load Average
- Disk
- Network
などを記録すること。
サービスはpmcd
Oracle Cloud Agent：
- OCIコンソールで監視できるようにする
- OCIコンソールからのRun Commandの実行
- OS Management
コンソールの機能は一部失われるが、LinuCの勉強だけなら停止しても問題ない？
⑦ サービスの停止
試験的に
oracle-cloud-agent
pmcd
を停止した。その結果、free -h結果に少し余裕ができた。
OCIコンソールはCPU・Memoryグラフでも利用率低下が確認できた
(→その後見えなくなった)
つまり今回止めたサービスは実際にリソースを消費していたことが分かった。
今日覚えたコマンド
| 目的 | コマンド |
|---|---|
| 前回起動ログ | journalctl -b -1 |
| 起動一覧 | journalctl --list-boots |
| エラーのみ | journalctl -p err |
| サービスログ | journalctl -u sshd |
| 時間指定 | journalctl --since ... --until ... |
| カーネルログ | journalctl -k |
| メモリ | free -h |
| プロセス順位 | ps aux --sort=-%mem |
| サービス一覧 | systemctl list-unit-files |
| 起動中サービス | systemctl --type=service --state=running |
| サービス停止 | sudo systemctl stop <サービス名> |
| サービス状態 | systemctl status <サービス名> |
| cgroup確認 | systemd-cgtop |
今回の調査結果
今回の調査では、
- SSHへの大量アクセスは確認できたが、異常ではなく一般的なインターネットスキャンだった。
- カーネルログにも、操作が固まる直接原因となるような OOM（メモリ不足による強制終了）やディスクエラーは見つからなかった。
- 一方で、Always Free（約500MBメモリ）の環境に対して、PCP や Oracle Cloud Agent が比較的大きな割合のメモリを使用していることが分かった。
- これらを停止すると、
free -hや OCIのメトリクス上でもメモリ使用量が減少し、対策が実際にリソースへ影響していることを確認できた。
現時点では「SSHが固まる原因を完全に特定した」とは言えないが、不要な常駐サービスを減らしてリソースに余裕を作るという改善は確認できた。
今日の学び
個人的には、この一連の流れで一番大きかったのは「コマンドを覚えたこと」ではなく、障害対応の進め方を体験できたことだと思う。
- まず現象を整理する
- ログで事実を確認する
- リソースを測定する
- 仮説を立てる
- 変更を加える
- 結果を測定して効果を確認する
このサイクルは、Linuxだけでなくクラウドやネットワーク機器、業務システムの障害対応でも共通する基本的な考え方であり、今日の調査はその練習として非常に実践的な内容だった。