Lệnh reboot Linux: reboot, shutdown -r now, systemctl reboot

Lệnh reboot Linux: reboot, shutdown -r now và systemctl reboot

Trên mọi bản phân phối hiện nay, ba lệnh dưới đây khởi động lại máy theo đúng cùng một cách. Hãy chạy một trong số đó với quyền root hoặc qua sudo; qua SSH, tài khoản không có đặc quyền sẽ nhận thông báo Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Đây không phải ba cách triển khai khác nhau. Trên các bản phân phối dùng systemd, /sbin/reboot, /sbin/shutdown, /sbin/halt và /sbin/poweroff đều là liên kết tượng trưng (symlink) tới systemctl, chương trình này kiểm tra tên mà nó được gọi rồi chuyển sang chế độ tương thích tương ứng; ls -l $(which reboot) sẽ cho thấy liên kết đó. Dù bạn gõ cách nào, systemd cũng khởi chạy reboot.target, dừng mọi unit theo thứ tự phụ thuộc ngược, gỡ gắn kết các hệ thống tệp và yêu cầu kernel khởi động lại. Qua SSH, kết nối sẽ rớt trong một hai giây; máy vắng mặt bao lâu còn tùy vào kernel, vào việc kiểm tra hệ thống tệp và vào quy trình khởi động của nhà cung cấp, vì vậy hãy chờ khoảng một phút trước khi nghĩ rằng có sự cố.

Tắt máy: shutdown -h now, poweroff, halt và init 6 kiểu cũ

Để tắt máy, dùng một trong hai lệnh sau:

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

Dưới systemd, -h nghĩa là "dừng hoặc tắt nguồn, tùy cái nào là mặc định", và mặc định là tắt nguồn, nên shutdown -h now và shutdown -P now giống hệt nhau. Lệnh hay khiến người dùng mắc bẫy là halt trơn: nó dừng hệ điều hành nhưng không bao giờ gửi yêu cầu tắt nguồn, nên máy ảo dừng ở trạng thái System halted, vẫn được cấp phát tài nguyên và vẫn bị tính phí, cho đến khi bạn dừng nó từ bảng điều khiển. Hãy dùng halt -p, poweroff hoặc shutdown -h now thay thế.

Các dạng lệnh SysV vẫn hoạt động vì systemd ánh xạ runlevel sang target: init 6 và telinit 6 trỏ tới reboot.target, init 0 trỏ tới poweroff.target. Chúng vô hại trong một script cũ nhưng không có thông báo 'wall', không hẹn giờ được và không ghi chú vào journal, nên chẳng có lý do gì để gõ tay.

Hẹn giờ reboot, hủy lệnh và cảnh báo người dùng đang đăng nhập

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

Thời gian có thể là now, +m tức m phút kể từ bây giờ, hoặc hh:mm theo định dạng 24 giờ (một giờ đã qua trong hôm nay nghĩa là ngày mai). Nếu không ghi thời gian, shutdown mặc định là +1: một lệnh sudo shutdown trơn sẽ tắt máy sau sáu mươi giây. Mọi thứ sau tham số thời gian được phát dưới dạng thông báo 'wall' (thông báo toàn hệ thống) tới mọi terminal đang đăng nhập, và logind nhắc lại cảnh báo khi gần tới hạn; --no-wall tắt thông báo, còn shutdown -k gửi cảnh báo mà không hẹn lịch gì cả. Năm phút trước hạn, logind tạo /run/nologin, và từ đó các lượt đăng nhập mới bị từ chối.

shutdown -c hủy thao tác đang chờ, xóa /run/nologin và báo cho người dùng đang đăng nhập rằng lệnh tắt máy đã bị hủy. Để kiểm tra xem có lệnh nào đang chờ không, hãy tìm /run/systemd/shutdown/scheduled: tệp này chỉ tồn tại khi có lệnh tắt máy trong hàng đợi và ghi lại chế độ cùng thời điểm đích. Các bản systemd gần đây cũng chấp nhận systemctl reboot --when=+10m, cùng với --when=show và --when=cancel (xem systemctl --help; các bản cũ hơn không có).

Điều gì xảy ra với dịch vụ và phiên SSH khi reboot

Khi reboot.target được yêu cầu, systemd dừng mọi thứ xung đột với nó, tức gần như mọi unit. Các dịch vụ dừng theo thứ tự phụ thuộc ngược: mỗi dịch vụ chạy ExecStop của mình hoặc nhận SIGTERM, và nếu vẫn chưa thoát sau TimeoutStopSec (mặc định 90 giây, lấy từ DefaultTimeoutStopSec= trong /etc/systemd/system.conf) thì sẽ nhận SIGKILL. Khoảng chờ đó chính là bộ đếm ngược A stop job is running for ... bạn thấy trên console; thường là do một daemon phớt lờ SIGTERM hoặc một cơ sở dữ liệu vẫn đang ghi dữ liệu xuống đĩa. Sau đó các hệ thống tệp được gỡ gắn kết hoặc gắn lại ở chế độ chỉ đọc và kernel khởi động lại. Bạn không cần chạy sync trước.

Phiên SSH của bạn không được đối xử đặc biệt. ssh.service dừng, scope chứa phiên đăng nhập của bạn nhận SIGTERM, shell bị đóng và client in ra Connection to 203.0.113.10 closed by remote host. Một server tmux hay screen bảo vệ bạn khi mất kết nối, chứ không bảo vệ khi reboot: mọi thứ chạy bên trong cũng mất theo.

Những gì chạy lại được quyết định bởi trạng thái kích hoạt, không phải bởi những gì đang chạy. Các unit đánh dấu enabled sẽ khởi động lại; còn mọi thứ chạy tay bằng systemctl start, một tiến trình nohup hay một container Docker không có chính sách khởi động lại thì không. Hãy chạy systemctl list-unit-files --state=enabled trước và systemctl --failed sau; hướng dẫn liệt kê và lọc dịch vụ bằng systemctl giải thích cách đọc cả hai.

Reboot VPS an toàn: danh sách kiểm tra trước khi chạy

Với VPS bạn không có quyền truy cập vật lý, nên một lần reboot không lên lại đồng nghĩa với việc phải vòng qua console của nhà cung cấp. Năm bước kiểm tra, tổng cộng chưa tới một phút, giúp tránh gần như mọi tình huống đó.

1. Xác nhận rằng thật sự cần reboot

Không phải bản cập nhật nào cũng cần reboot. Trên Ubuntu, /var/run/reboot-required xuất hiện khi một gói yêu cầu khởi động lại và /var/run/reboot-required.pkgs ghi tên gói đó; needrestart trên Debian và Ubuntu, và needs-restarting -r từ dnf-utils trên họ RHEL, làm cùng việc kiểm tra ở các hệ khác. Kernel, glibc hay systemd mới thì đáng reboot; một nginx vừa vá chỉ cần systemctl restart nginx. Hãy cài các bản cập nhật đang chờ trước để chỉ reboot một lần chứ không phải hai; bài hướng dẫn cập nhật Ubuntu bằng dòng lệnh trình bày trình tự apt và cờ reboot-required.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. Đảm bảo không có gì đang ghi dở

Ngắt ngang trình quản lý gói là con đường nhanh nhất dẫn tới một hệ thống cấu hình dở dang, và một bản sao lưu bị dừng giữa chừng là một tệp mà sau này bạn sẽ tưởng nhầm là bản sao tốt. Hãy tìm các tiến trình đó và xem còn ai khác đang đăng nhập:

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. Kiểm tra cấu hình phải vượt qua được lần khởi động

Có ba tệp có thể biến một lần reboot bình thường thành bị khóa ngoài. Lỗi cú pháp trong sshd_config khiến sshd không khởi động và bạn không vào lại được: sudo sshd -t không in gì nếu tệp hợp lệ, và nếu gần đây bạn đã gia cố daemon SSH, hãy chạy nó ngay. Một dòng trong /etc/fstab trỏ tới thiết bị không còn tồn tại sẽ đẩy quá trình khởi động vào chế độ khẩn cấp (emergency mode) trừ khi dòng đó có nofail; sudo findmnt --verify phát hiện được phần lớn trường hợp này. Một phân vùng /boot đầy có thể để lại kernel cài dở, nên hãy kiểm tra dung lượng trống. Các luật tường lửa viết trực tiếp bằng iptables hoặc nft mà chưa lưu sẽ biến mất khi reboot; luật của UFW và firewalld thì được giữ lại.

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. Ghi lại trạng thái gốc

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. Reboot rồi kiểm tra

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

uname -r khớp, systemctl --failed sạch và diff rỗng nghĩa là lần reboot đã hoàn thành nhiệm vụ.

Khi reboot bị treo: ép khởi động lại, và khi nào nên dùng console của nhà cung cấp

Nếu reboot trả về nhưng máy không bao giờ tắt, tức là một stop job đang bị kẹt; systemctl list-jobs cho biết đó là job nào. systemctl reboot --force bỏ qua bước dừng unit có trật tự: các tiến trình bị kết thúc ngay nhưng hệ thống tệp vẫn được gỡ gắn kết, nên tuy đột ngột nhưng khá an toàn. --force --force khởi động lại ngay lập tức mà không gỡ gắn kết gì và có thể làm mất dữ liệu; hãy coi nó như rút phích cắm. Giao diện SysRq của kernel là cứu cánh cuối cùng khi chính systemd không còn phản hồi. Root luôn được phép ghi vào /proc/sysrq-trigger bất kể sysctl kernel.sysrq đặt thế nào, nhưng phép chuyển hướng phải chạy với quyền root, nên hãy dùng shell root hoặc sudo sh -c:

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

Hãy dùng đến bảng điều khiển hoặc console của nhà cung cấp khi máy khách không còn tự xoay xở được: SSH không truy cập được sau khi thay đổi mạng hoặc tường lửa, kernel bị panic khi khởi động, dấu nhắc chế độ khẩn cấp do một dòng fstab sai, quên mật khẩu root. Reboot hoặc Shutdown trong bảng điều khiển thường gửi một sự kiện nguồn ACPI mà hệ thống khách xử lý qua logind (HandlePowerKey= trong logind.conf), nên các dịch vụ vẫn dừng gọn gàng. Reset, Force stop hoặc Power cycle cắt nguồn ảo mà không báo trước: journal của hệ thống tệp được phát lại ở lần khởi động sau, nhưng mọi dữ liệu chưa ghi đều mất. Console VNC hoặc console nối tiếp (serial) là thứ cho phép bạn xem GRUB, thông báo kernel và shell khẩn cấp mà SSH không bao giờ hiển thị.

Kiểm tra uptime và lần khởi động lại gần nhất của máy

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

uptime -s và who -b in trực tiếp thời điểm khởi động. last -x đọc /var/log/wtmp và liệt kê cả bản ghi reboot lẫn shutdown: một dòng reboot không có dòng shutdown nào trước đó nghĩa là máy đã tắt không đúng cách (kernel panic hoặc reset cứng). journalctl --list-boots đánh số mọi lần khởi động mà journal biết, 0 là lần hiện tại và -1 là lần trước; sau đó journalctl -b -1 -e hiển thị những dòng cuối cùng trước lần tắt máy trước, nơi một stop job quá thời gian hoặc một tiến trình bị kill do hết bộ nhớ để lại dấu vết. Nếu chỉ thấy lần khởi động hiện tại, journal đang ở chế độ tạm thời (volatile): hãy tạo /var/log/journal rồi khởi động lại systemd-journald.

Mọi lệnh ở trên đều dựa trên một giả định: khi hệ thống khách không chịu lên lại, bạn vẫn có thể truy cập nó. Một VPS Linux KVM có quyền truy cập console cho bạn đúng điều đó: một máy ảo thực thụ với kernel riêng, CPU và RAM chuyên dụng, toàn quyền root, và một console cho những ngày SSH không dùng được. rdp.monster giao máy trong khoảng 10 giây sau khi thanh toán được xác nhận, với băng thông không giới hạn (sử dụng hợp lý), không cần KYC, chấp nhận thẻ và tiền mã hóa, giá từ $8.99/tháng.