前幾天我架在 Google Cloud Platform (GCP) 虛擬機器上的 WordPress 突然連不上，

想用 gcloud 指令 ssh 進機器看看狀況，竟也連不上…

 

先用大絕招，在 GCP 主控台 > Compute Engine > 虛擬機器上，

按「重設」按鈕，讓電腦重開機，

可是，過了幾分鐘後，gcloud ssh 連不上也就算了，

連 IP 都 ping 不到，這下可怎麼辦了呢？

 

後來是利用 備份現有的 WordPress Multisite 多站台，遷移至新的 GCP 帳號 的做法，

建立了一台新的虛擬機器，再把之前用 UpdraftPlus 存到 Google Drive 的備份，

還原到新的虛擬機器，這才解決了困境…

至於之前舊虛擬機器出了什麼問題，無從得知…

 

沒想到，過了兩天，我幫家人架的虛擬機器也遇到了一模一樣的問題，

但麻煩的是，因為那台虛擬機剩餘空間比我的還少，

所以並沒有成功的使用 UpdraftPlus 備份，

因此建立新虛擬機再轉移過去的方案不能適用…

懷疑是 UpdraftPlus 在定期備份時，

因為空間不足，使得機器整個卡住 (hang)，

但因為 ssh 連不進去，難以查證…

重點是也無法去刪除多餘的檔案來釋出空間…

 

上網查了一下，有人提到可以加大 (resize) GCP 上的硬碟空間，

但如果虛擬機作業系統本身不支援自動調整大小 (automatic partition resize)  的話，

就還得登入作業系統去調整，才能用到加大後的空間…

不確定那台虛擬機有沒有這功能…

 

後來看到另一個救命的方案，原來 GCP 上是可以用串列埠 (serial port) 連線的，

這樣就能看到 Linux 文字主控台上的訊息了～

到 GCP > Compute Engine > VM 執行個體 > 選擇虛擬機器 > 編輯，

把遠端存取 > 啟用序列埠連線 打勾後，按下儲存：

 

上面這個序列埠啟用，在 VM 開機狀態也能設定，

因此可以在保留現場環境的狀態下，

立刻用連線至序列主控台 > 序列埠 1 (主控台) 連線過去：

 

連線後，立刻可以看到主控台上的訊息：

 

很意外的，主控台上的訊息是 mysqld 吃掉了太多的記憶體 (Out of memory)，

而不是硬碟空間爆掉…

猜測是原本機器剩的 RAM 就不多，

在執行 UpdraftPlus 備份時，它會將資料庫的內容傾印 (dump) 出來，

這個過程有可能會耗掉大量的記憶體…

 

將機器強制重新啟動之後，在主控台看到新的錯誤訊息，

看來是因為強制關機的關係，導致硬碟出了些問題，必須用 fsck 檢查…

而當這訊息出現時，機器的開機過程就等於停下來了，

這可能就是我前一台機器遇到的狀況：

Begin: Will now check root file system ... fsck from util-linux 2.29.2
[/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 
/dev/sda1: recovering journal
[    2.122403] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input2
[    2.144659] tsc: Refined TSC clocksource calibration: 2499.908 MHz
[    2.146822] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2408e31416c, max_idle_ns: 440795285898 ns
/dev/sda1 contains a file system with errors, check forced.
/dev/sda1: Inodes that were part of a corrupted orphan linked list found.  
/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
fsck exited with status code 4
done.
Failure: File system check of the root filesystem failed
The root filesystem on /dev/sda1 requires a manual fsck

BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) 

 

因為已經出現了 (initramfs) 命令列提示符號，

因此就執行了 fsck /dev/sda1 指令，

把所有 fsck 找到的錯誤都按 y 修復：

Inode 142079 was part of the orphaned inode list.  FIXED.
Inode 529792 was part of the orphaned inode list.  FIXED.
Inode 529793 was part of the orphaned inode list.  FIXED.
Inode 530010 was part of the orphaned inode list.  FIXED.
Inode 530011 was part of the orphaned inode list.  FIXED.
Inode 532227 extent tree (at level 1) could be narrower.  Fix? yes
Inode 537940 was part of the orphaned inode list.  FIXED.
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(231301--232223) -(622888--622895) -(622907--622924) -(622968--622993)
Fix? yes
Free blocks count wrong for group #7 (704, counted=1627).
Fix? yes
Free blocks count wrong for group #19 (10681, counted=10733).
Fix? yes
Free blocks count wrong (280698, counted=944588).
Fix? yes
Inode bitmap differences:  -7016 -11699 -142072 -142074 -142079 -(529792--529793) -(530010--530011) -537940
Fix? yes
Free inodes count wrong for group #0 (0, counted=1).
Fix? yes
Free inodes count wrong for group #1 (0, counted=1).
Fix ('a' enables 'yes' to all) ? yes
Free inodes count wrong for group #17 (0, counted=3).
Fix ('a' enables 'yes' to all) ? yes to all
Free inodes count wrong for group #64 (0, counted=4).
Fix? yes
Free inodes count wrong for group #65 (1511, counted=1512).
Fix? yes
Free inodes count wrong (488538, counted=530661).
Fix? yes
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 124699/655360 files (0.5% non-contiguous), 1676335/2620923 blocks

 

fsck 完成之後，還是停留在 shell 裡面，

輸入 exit 指令離開，它看起來就繼續開機流程，順利開完機了：

Nov 17 23:35:14 wordpress-multisite-1-vm systemd[1]: Time has been changed
Nov 17 23:35:14 wordpress-multisite-1-vm systemd[1]: apt-daily-upgrade.timer: Adding 19min 27.380945s random time.
Nov 17 23:35:14 wordpress-multisite-1-vm systemd[1]: apt-daily.timer: Adding 4h 15min 4.817806s random time.
Nov 17 23:35:14 wordpress-multisite-1-vm google-clock-skew: INFO Synced system time with hardware clock.
Debian GNU/Linux 9 wordpress-multisite-1-vm ttyS0
wordpress-multisite-1-vm login: [  216.877976] bitnami[657]: /opt/bitnami/mysql/scripts/ctl.sh : mysql  started at 
port 3306
......
Nov 17 23:35:56 wordpress-multisite-1-vm systemd[1]: Reached target Graphical Interface.
Nov 17 23:35:56 wordpress-multisite-1-vm systemd[1]: Starting Update UTMP about System Runlevel Changes...
Nov 17 23:35:56 wordpress-multisite-1-vm systemd[1]: Started Update UTMP about System Runlevel Changes.
Nov 17 23:35:56 wordpress-multisite-1-vm systemd[1]: Startup finished in 3min 13.703s (kernel) + 57.669s (userspace
) = 4min 11.373s.

 

這次多虧了序列埠連線，順利的解決了 GCP 上 VM 無法開機的問題，

要不然原本可是要再重建一台虛擬機器的…

不過 VM 記憶體/磁碟空間不足的問題，之後也還是得解決啊…

 

參考資料：

stackoverflow: Disk is full, and I can’t SSH to instance

GCP: Interacting with the Serial Console