概要
- 物理的な再起動の前に、OSの再起動を行うとよい。
環境
[syslogserver@alma01 ~]$ cat /etc/redhat-release
AlmaLinux release 9.0 (Emerald Puma)
-
ハードウェアはMinisforum N40。Win10Proが入っていたものに、USBメモリからAlmaLinuxを入れ、Syslogサーバとして運用している。
-
YAMAHA RTX1300やSynology NAS（サーバラックに複数台）、あとはアクセスポイントからのsyslogをrsyslogで受けて、マウントさせたNASに飛ばしている。logrotateを設定している。
-
経路はインターネット→RTX1300→L2スイッチ→N40。
障害が発生するまで
- 数日前に施設点検で施設全体の電力供給が落ちた。その際、N40の電源を落とした。
- 電力供給復旧後、N40の電源を入れ直す。翌日、自宅からRTX1300経由でVPNにて入り、N40にSSH接続しようとすると、重くて入れない。
- "ping 192.168.1.100"(N40のローカルIPアドレス)を打つと、不安定な結果となる。
saitoh@MBP:~$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=6559 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=5535 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=4511 ms
64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=3487 ms
64 bytes from 192.168.1.100: icmp_seq=5 ttl=64 time=2463 ms
64 bytes from 192.168.1.100: icmp_seq=6 ttl=64 time=1439 ms
64 bytes from 192.168.1.100: icmp_seq=7 ttl=64 time=416 ms
64 bytes from 192.168.1.100: icmp_seq=8 ttl=64 time=282 ms
64 bytes from 192.168.1.100: icmp_seq=9 ttl=64 time=0.271 ms
64 bytes from 192.168.1.100: icmp_seq=10 ttl=64 time=0.234 ms
64 bytes from 192.168.1.100: icmp_seq=11 ttl=64 time=0.180 ms
64 bytes from 192.168.1.100: icmp_seq=12 ttl=64 time=0.227 ms
64 bytes from 192.168.1.100: icmp_seq=13 ttl=64 time=5.83 ms
64 bytes from 192.168.1.100: icmp_seq=14 ttl=64 time=0.313 ms
64 bytes from 192.168.1.100: icmp_seq=15 ttl=64 time=0.223 ms
64 bytes from 192.168.1.100: icmp_seq=16 ttl=64 time=0.209 ms
64 bytes from 192.168.1.100: icmp_seq=17 ttl=64 time=0.241 ms
64 bytes from 192.168.1.100: icmp_seq=18 ttl=64 time=9339 ms
64 bytes from 192.168.1.100: icmp_seq=19 ttl=64 time=8316 ms
64 bytes from 192.168.1.100: icmp_seq=20 ttl=64 time=7292 ms
64 bytes from 192.168.1.100: icmp_seq=21 ttl=64 time=6269 ms
64 bytes from 192.168.1.100: icmp_seq=22 ttl=64 time=5245 ms
64 bytes from 192.168.1.100: icmp_seq=23 ttl=64 time=4222 ms
64 bytes from 192.168.1.100: icmp_seq=24 ttl=64 time=3198 ms
64 bytes from 192.168.1.100: icmp_seq=25 ttl=64 time=2174 ms
64 bytes from 192.168.1.100: icmp_seq=26 ttl=64 time=1150 ms
64 bytes from 192.168.1.100: icmp_seq=27 ttl=64 time=127 ms
64 bytes from 192.168.1.100: icmp_seq=28 ttl=64 time=452 ms
64 bytes from 192.168.1.100: icmp_seq=29 ttl=64 time=125 ms
^C
--- 192.168.1.100 ping statistics ---
30 packets transmitted, 29 received, 3.33333% packet loss, time 29532ms
rtt min/avg/max/mdev = 0.180/2503.664/9339.012/2897.330 ms, pipe 10
対処
9000msとかおかしくね？ということで、ハードウェアの不具合を行う。
幸い、サーバールーム前にいる社員がいたので、
- 電源長押しで再起動（後から知ったのだが、Minisforum N40は電源長押しだけではなく、ACアダプタを抜く必要があるらしい）
- L2スイッチ側の差し込み口を変更
- LANケーブルを新品に交換
を依頼。しかし、状況改善せず。
ようやくSSHには入れるものの・・・
[syslogserver@alma01 ~]$ free
Message from syslogd@alma01 at May 15 18:50:25 ...
kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [swapper/1:0]
Message from syslogd@alma01 at May 15 18:50:49 ...
kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/1:2H:1286]
Message from syslogd@alma01 at May 15 18:51:13 ...
kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [swapper/1:0]
pingもたまに"Destination Host Unreachable"が返ってくる始末。
From 192.168.1.241 icmp_seq=67 Destination Host Unreachable
途方に暮れて、出社して実際にあれこれ試す必要があるのかと思い、「そう言えば、再起動は再起動でも、なかなかSSHからコマンドが通らなかったから、OS側の再起動はしていなかったな」ということで、ようやくSSHログインが通った瞬間に下記を実行。
sudo shutdown -r now
ちなみに、この入力自体も、一文字一文字ラグがあって、なかなか入力できなかった。
数分後…
saitoh@MBP:~$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.797 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.485 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.477 ms
64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=0.481 ms
64 bytes from 192.168.1.100: icmp_seq=5 ttl=64 time=0.480 ms
普通に治ってるんですけど…。
[sv10mk2@alma01 ~]$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 3173028 5248 179132 0 0 79 5 61 90 0 0 99 0 0
こちらも異常なし。
どうやら、なんらかの理由でサーバの処理が追いついていなかったようだった。