Khi quản trị máy chủ Linux, tình huống VPS đột ngột khởi động lại mà không rõ lý do là một trong những sự cố gián đoạn khó chẩn đoán nhất.
Dấu hiệu nhận biết sự cố thường là thời gian hoạt động (uptime) bị đưa về 0 phút hoặc hệ thống giám sát gửi cảnh báo mất kết nối tạm thời. Khi bạn đăng nhập vào kiểm tra, các dịch vụ web, cơ sở dữ liệu hay container đều đã tự động chạy lại bình thường. File log của ứng dụng thường chỉ dừng lại ở một mốc thời gian nhất định mà không ghi nhận bất kỳ cảnh báo hay lỗi ngoại lệ nào trước đó.
Nếu không tìm ra nguyên nhân gốc rễ, sự cố này sẽ tiếp tục lặp lại vào các chu kỳ tiếp theo, đặc biệt vào các khung giờ chạy tác vụ định kỳ như sao lưu dữ liệu, bảo trì hệ thống hoặc quét bảo mật ban đêm. Hãy tuân thủ nguyên tắc ghi nhận hiện trường tại Quy trình 30 phút đầu khi website gặp sự cố để tránh làm mất các manh mối quan trọng trong log.
Phân biệt giữa khởi động lại tuần tự (Clean Reboot) và mất nguồn đột ngột (Hard Crash) trên Linux.
Clean Reboot và Hard Crash
Để khoanh vùng chính xác phạm vi điều tra, trước hết bạn cần phân loại lần khởi động lại đó thuộc nhóm nào:
1. Khởi động lại có kiểm soát (Clean Reboot)
Đây là trường hợp hệ điều hành chủ động thực hiện chu trình tắt máy tuần tự thông qua systemd:
- Systemd gửi tín hiệu dừng mềm (
SIGTERM) đến các tiến trình để ứng dụng kịp đóng kết nối và lưu dữ liệu. - Sau thời gian chờ (mặc định 90 giây), nếu tiến trình chưa dừng, systemd gửi tiếp tín hiệu buộc dừng (
SIGKILL). - Hệ thống đẩy toàn bộ dữ liệu từ bộ đệm RAM xuống đĩa cứng (sync buffer) và chuyển các phân vùng sang trạng thái chỉ đọc (read-only) trước khi khởi động lại.
Dấu hiệu đặc trưng: Log hệ thống ghi lại đầy đủ chuỗi thông báo tắt máy tuần tự như Starting Reboot... hoặc Stopping All Services... cho đến giây cuối cùng.
2. Mất nguồn hoặc sập hệ điều hành đột ngột (Hard Crash)
Đây là tình huống máy ảo bị ngắt nguồn tức thì hoặc nhân Linux gặp lỗi nghiêm trọng không thể tiếp tục vận hành:
- Máy chủ vật lý của nhà cung cấp (Host Node Hypervisor) bị mất điện, lỗi phần cứng hoặc máy ảo bị ép khởi động lại từ bảng điều khiển bên ngoài.
- Nhân Linux gặp lỗi Kernel Panic do lỗi bộ nhớ vật lý hoặc lỗi hệ thống tệp tin nghiêm trọng.
- Cơ chế Hardware Watchdog tự động reset máy khi nhân Linux bị treo hoàn toàn và không phản hồi tín hiệu nhịp tim.
Dấu hiệu đặc trưng: Dòng log cuối cùng của phiên hoạt động trước bị cắt đứt ngang. Không có thông báo tắt máy nào từ systemd, và dòng kế tiếp trong file nhật ký là thông báo nạp nhân của phiên boot mới.
Bước 1: Xác định chính xác thời điểm và loại tắt máy
Trước khi đọc chi tiết từng file log dài hàng ngàn dòng, bạn cần xác định chính xác thời điểm máy chủ bị khởi động lại và hệ điều hành ghi nhận lần tắt máy đó như thế nào.
1. Kiểm tra lịch sử khởi động lại bằng lệnh last
Lệnh last đọc dữ liệu từ file nhị phân /var/log/wtmp để hiển thị lịch sử đăng nhập, tắt máy và khởi động lại của hệ thống:
# Xem danh sách các lần reboot gần nhất kèm mốc thời gian
last -x reboot shutdown | head -n 10Kết quả trả về thường có dạng sau:
reboot system boot 6.8.0-45-generic Sun Oct 18 03:15 still running
shutdown system down 6.8.0-45-generic Sun Oct 18 03:14 - 03:15 (00:01)
reboot system boot 6.8.0-45-generic Fri Oct 16 10:00 - 03:14 (1+17:14)Cách phân tích đầu ra:
- Nếu xuất hiện dòng
shutdown system downngay trước dòngreboot system boot: Hệ thống đã thực hiện quy trình tắt máy tuần tự (Clean Reboot). Mốc thời gian03:14chính là thời điểm lệnh tắt máy được phát ra. - Nếu chỉ xuất hiện dòng
reboot system bootmà không có dòngshutdown system downtương ứng phía trước: Hệ điều hành đã bị dừng đột ngột (Hard Crash). Kernel không kịp ghi sự kiện shutdown vào file/var/log/wtmp. - Nếu xuất hiện trạng thái
crash: Lệnhlastphát hiện phiên làm việc trước kết thúc bất thường do mất nguồn hoặc kernel panic.
2. Xác định thời điểm khởi động lại chính xác đến từng giây
Để đối chiếu với các hệ thống giám sát bên ngoài hoặc log của proxy CDN (như Cloudflare), bạn cần biết chính xác thời điểm phiên làm việc hiện tại bắt đầu:
# Xem thời điểm hệ thống bắt đầu khởi động
uptime -sKết quả trả về mốc thời gian chi tiết theo định dạng YYYY-MM-DD HH:MM:SS, ví dụ: 2026-10-18 03:14:52.
Ngoài ra, bạn có thể kiểm tra danh sách các phiên boot được systemd-journald lưu trữ:
# Liệt kê tất cả các phiên boot có lưu log trên máy chủ
journalctl --list-bootsCột đầu tiên hiển thị số thứ tự phiên boot:
0: Phiên boot hiện tại đang chạy.-1: Phiên boot ngay trước lần khởi động lại gần nhất.-2: Phiên boot trước đó nữa.
Việc xác định được phiên boot -1 kèm mốc thời gian cụ thể là chìa khóa để bạn truy xuất chính xác những giây cuối cùng của hệ thống ở bước tiếp theo.
Bước 2: Đọc log của phiên hoạt động trước qua journalctl và syslog
Sau khi đã xác định được mốc thời gian máy chủ tắt, bước tiếp theo là đọc nội dung log được ghi nhận ngay trước thời điểm đó.
1. Truy xuất những giây cuối cùng của phiên boot trước bằng journalctl
Công cụ hiệu quả nhất trên các bản phân phối Linux sử dụng systemd là journalctl (tham khảo chi tiết tại systemd journalctl manual). Để xem những dòng log cuối cùng của phiên hoạt động trước phiên hiện tại, bạn dùng cờ -b -1:
# Xem 100 dòng log cuối cùng của phiên boot trước đó (-b -1)
journalctl -b -1 -n 100 --no-pagerNếu muốn theo dõi từ một mốc thời gian cụ thể (ví dụ 10 phút trước thời điểm reboot lúc 03:14):
# Lọc log của phiên trước từ 03:00 đến 03:15
journalctl -b -1 --since "2026-10-18 03:00:00" --until "2026-10-18 03:15:00" --no-pagerCách phân tích log của phiên boot trước:
- Trường hợp xuất hiện thông báo shutdown tuần tự: Bạn sẽ thấy các dòng log từ
systemd-logindhoặcsystemdthông báo lệnh tắt máy được kích hoạt từ đâu:
systemd-logind[650]: System is rebooting.
systemd[1]: Starting Reboot...
systemd[1]: Stopping User Manager for UID 1000...
systemd[1]: Stopped target Multi-User System.Dấu hiệu này cho thấy máy chủ được khởi động lại theo yêu cầu của một phần mềm hoặc tiến trình nội bộ, không phải do lỗi phần cứng.
- Trường hợp log bị đứt ngang đột ngột: Những dòng log cuối cùng là các hoạt động bình thường của ứng dụng (như Nginx ghi log access, cron chạy định kỳ), sau đó log dừng hẳn mà không có bất kỳ thông báo shutdown nào. Dòng tiếp theo khi chạy lệnh
journalctl -b 0(phiên hiện tại) sẽ là:
-- Boot 1a2b3c4d... --
kernel: Linux version 6.8.0-45-generic ...Điều này xác nhận hệ điều hành bị mất nguồn đột ngột hoặc kernel bị đóng băng tức thì khiến buffer log không kịp lưu xuống đĩa.
2. Kiểm tra log nhân Linux (kern.log) và syslog truyền thống
Nếu hệ thống có cài đặt rsyslog (thường lưu tại /var/log/syslog hoặc /var/log/messages), hãy mở file log cũ để đối chiếu:
# Tìm các dòng log trước mốc thời gian reboot trong syslog
grep -E "reboot|shutdown|panic|oom" /var/log/syslog | tail -n 20Kiểm tra riêng file log của kernel (/var/log/kern.log) để tìm các cảnh báo nghiêm trọng từ phần cứng hoặc driver:
# Kiểm tra log kernel xung quanh thời điểm tắt máy
sudo grep -i -E "kernel panic|hardware error|watchdog|mce" /var/log/kern.logNếu tìm thấy các từ khóa như Kernel panic - not syncing, Machine Check Exception (MCE) hoặc Watchdog timer expired, nguyên nhân trực tiếp là do lỗi ở tầng nhân Linux hoặc sự cố phần cứng vật lý trên máy chủ host.
Bước 3: Phân loại và kiểm tra 3 nguyên nhân thường gặp nhất
Từ kết quả phân tích log ở Bước 2, bạn có thể đối chiếu vào 3 kịch bản phổ biến nhất dưới đây để xác định chính xác nguồn gốc sự cố:
1. Cơ chế cập nhật tự động (Unattended Upgrades) tự khởi động lại máy
Đây là nguyên nhân phổ biến nhất đối với các lần khởi động lại diễn ra vào ban đêm (thường rơi vào khoảng từ 2h đến 6h sáng) và có đầy đủ log tắt máy tuần tự của systemd.
Trên các bản phân phối như Ubuntu và Debian, gói phần mềm unattended-upgrades (tham khảo tài liệu Ubuntu Community - Automatic Updates) được cài đặt sẵn để tự động tải và cài các bản vá bảo mật. Khi một bản cập nhật nhân Linux (kernel) mới được cài đặt, hệ thống có thể được cấu hình tự động reboot để áp dụng kernel mới nếu file cấu hình có chỉ thị Unattended-Upgrade::Automatic-Reboot "true";.
Cách kiểm tra: Mở file log riêng của tiến trình nâng cấp tự động:
# Kiểm tra log nâng cấp tự động
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -n 50Nếu trong log xuất hiện các dòng như:
Packages that were upgraded: linux-image-6.8.0-45-generic
Found /var/run/reboot-required, rebooting...Bạn có thể kết luận chắc chắn hệ thống vừa tự động reboot để nạp kernel mới.
2. Tràn bộ nhớ (Out-Of-Memory) khiến tiến trình hệ thống bị tắt hoặc Kernel Panic
Khi một tiến trình ứng dụng (như Java, Elasticsearch, MySQL hoặc worker xử lý nền) tiêu tốn quá nhiều RAM và không gian Swap bị cạn kiệt, cơ chế Out-Of-Memory Killer (OOM Killer) của Linux sẽ can thiệp để tắt bớt tiến trình nhằm giải phóng bộ nhớ.
Trong hầu hết trường hợp, OOM Killer chỉ tắt một tiến trình ứng dụng đơn lẻ (ví dụ tắt mysqld). Tuy nhiên, máy chủ có thể bị sập hoàn toàn hoặc khởi động lại nếu:
- OOM Killer buộc phải tắt một tiến trình thiết yếu của hệ thống (như
systemd-journaldhoặc tiến trình quản lý phiên). - Nhân Linux được cấu hình tự động reboot khi gặp tình trạng cạn RAM thông qua tham số
vm.panic_on_oom = 1.
Cách kiểm tra sự kiện OOM:
# Tìm kiếm vết tích OOM Killer trong log của phiên trước
journalctl -b -1 | grep -i -E "oom-killer|out of memory|killed process"Nếu có sự kiện OOM, bạn sẽ thấy thông báo chi tiết:
kernel: Out of memory: Killed process 1420 (mysqld) total-vm:4215040kB, anon-rss:1820400kB3. Sự cố từ hạ tầng máy chủ vật lý của nhà cung cấp (Host Node Hypervisor)
Nếu log của phiên trước bị cắt đứt ngang hoàn toàn, không có thông báo shutdown và cũng không ghi nhận bất kỳ sự kiện OOM nào, nguyên nhân thường nằm ở lớp ảo hóa bên ngoài:
- Máy chủ vật lý của nhà cung cấp bị mất nguồn đột ngột hoặc lỗi phần cứng (RAM ECC, ổ đĩa vật lý).
- Nhà cung cấp thực hiện di chuyển máy ảo (live migration) giữa các cụm node nhưng gặp lỗi khiến máy ảo bị reset.
- Kỹ sư của nhà cung cấp gửi lệnh Reboot cứng (Hard Reset) qua bảng điều khiển ảo hóa (KVM / VMware / Proxmox).
Trong trường hợp này, các file log bên trong máy ảo sẽ không thể ghi lại nguyên nhân. Bạn cần đối chiếu thời điểm uptime -s với bảng thông báo trạng thái mạng (Status page) hoặc gửi yêu cầu hỗ trợ (ticket) tới nhà cung cấp kèm mốc thời gian để họ tra cứu log trên máy chủ vật lý (Host Node).
Bước 4: Thiết lập lưu log bền vững và cấu hình phòng ngừa
Để không bị mất log khi xảy ra sự cố đột ngột trong tương lai và kiểm soát hoàn toàn việc khởi động lại của hệ điều hành, bạn nên thiết lập các cấu hình sau:
1. Đảm bảo systemd-journald lưu log bền vững xuống đĩa
Mặc định trên một số bản phân phối tối giản, systemd-journald chỉ lưu log trên bộ nhớ tạm (RAM) tại /run/log/journal. Khi máy chủ bị mất nguồn đột ngột, toàn bộ log của phiên trước sẽ biến mất, khiến bạn không thể dùng lệnh journalctl -b -1.
Để đảm bảo log được ghi bền vững xuống ổ cứng, mở file /etc/systemd/journald.conf:
[Journal]
# Bắt buộc lưu log xuống đĩa tại /var/log/journal
Storage=persistent
# Giới hạn dung lượng log tối đa trên đĩa (ví dụ 500MB)
SystemMaxUse=500MKhởi động lại dịch vụ journald để áp dụng:
sudo systemctl restart systemd-journald2. Tắt hoặc kiểm soát khung giờ tự động reboot của Unattended Upgrades
Nếu bạn muốn máy chủ chỉ reboot khi có sự giám sát của kỹ sư vận hành, hãy tắt tính năng tự động reboot trong file cấu hình /etc/apt/apt.conf.d/50unattended-upgrades:
// Chuyển giá trị thành false để cấm tự động khởi động lại
Unattended-Upgrade::Automatic-Reboot "false";Nếu vẫn muốn hệ thống tự động khởi động lại sau khi vá lỗi bảo mật nhưng chỉ được phép diễn ra vào khung giờ bảo trì cố định (ví dụ lúc 03:30 sáng):
Unattended-Upgrade::Automatic-Reboot "true";
// Thiết lập thời gian khởi động lại cụ thể
Unattended-Upgrade::Automatic-Reboot-Time "03:30";3. Cấu hình kiểm soát Kernel Panic và bộ nhớ Swap
Để tránh việc nhân Linux bị đóng băng vĩnh viễn khi gặp sự cố, bạn có thể thiết lập hệ thống tự động reboot sau 10 giây nếu xảy ra Kernel Panic bằng cách thêm vào file /etc/sysctl.conf:
# Tự động reboot sau 10 giây nếu bị Kernel Panic
kernel.panic = 10
# Không tự động panic khi bị tràn RAM (để OOM Killer xử lý tiến trình con)
vm.panic_on_oom = 0
# Tinh chỉnh mức độ ưu tiên dùng swap (giảm thiểu nguy cơ treo máy khi thiếu RAM)
vm.swappiness = 10Áp dụng cấu hình ngay mà không cần khởi động lại:
sudo sysctl -pĐồng thời, đảm bảo máy chủ luôn có ít nhất 1GB đến 2GB không gian Swap để làm vùng đệm, giúp hệ thống không bị crash đột ngột khi mức tiêu thụ RAM tăng vọt trong thời gian ngắn.
Tóm tắt quy trình kiểm tra khi VPS tự khởi động lại
Khi phát hiện máy chủ vừa bị khởi động lại, bạn tiến hành điều tra theo 4 bước:
- Xác định thời điểm: Chạy
uptime -svàlast -x reboot shutdownđể biết chính xác thời điểm và xem đó là Clean Reboot hay Hard Crash. - Đọc log phiên trước: Dùng lệnh
journalctl -b -1 -n 100để xem những giây cuối cùng trước khi máy chủ ngừng hoạt động. - Khoanh vùng nguyên nhân: Kiểm tra
unattended-upgrades.log(nếu là Clean Reboot) hoặc tìm vết tíchoom-killer/kernel panic(nếu là Hard Crash). - Củng cố hệ thống: Bật
Storage=persistentcho journald, kiểm soát lịch reboot tự động và duy trì dung lượng Swap an toàn.
Sau khi xác định được nguyên nhân gốc rễ, việc lưu lại báo cáo kỹ thuật là rất quan trọng để tránh lặp lại sự cố; tham khảo quy trình lập tài liệu tại bài Cách viết Post-Mortem cho sự cố nhỏ: Mẫu báo cáo và nguyên tắc không đổ lỗi. Nếu cần đánh giá lại quy trình khởi động lại máy chủ trong quá trình bảo trì, hãy xem thêm hướng dẫn Khi nào nên reboot VPS và khi nào chỉ cần restart service?.
