EQVPS

Giữ một bot chạy 24/7 trên một VPS (để nó không bao giờ lặng lẽ chết)

15 thg 6, 2026 · 3 phút đọc · EQVPS Team

Có hai cách một bot "không hoạt động" trên một máy chủ. Cái rõ ràng: nó dừng ngay khi bạn đóng SSH. Cái ranh mãnh: nó chạy tốt hai ngày, sập lúc 4 giờ sáng vì một lỗi không được xử lý, và bạn biết hàng giờ sau khi ai đó hỏi vì sao nó down. Cả hai có cùng cách sửa, và nó không phải "nhớ khởi động lại nó" — nó là giao việc cho systemd, thứ giữ mọi thứ lên để bạn không phải làm.

Vì sao nó chết khi bạn đăng xuất

Nếu bạn khởi chạy nó với python bot.py trong phiên SSH của bạn, tiến trình là một con của phiên đó. Đóng phiên, tiến trình đi theo nó. nohup& che đậy điều này, nhưng chúng cho bạn không khởi-động-lại-khi-sập và không khởi-động-lúc-boot — nên bạn đã giải quyết vấn đề nhỏ và giữ vấn đề lớn.

Cách sửa thật: một dịch vụ systemd

Đây là toàn bộ. Tạo /etc/systemd/system/mybot.service:

[Unit]
Description=My bot
After=network-online.target

[Service]
WorkingDirectory=/home/youruser/mybot
ExecStart=/home/youruser/mybot/venv/bin/python bot.py
Restart=always
RestartSec=5
User=youruser
Environment=API_KEY=...

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now mybot

Hai dòng đang làm việc nặng:

Khi nó vẫn cư xử sai — đọc các log

Một bot cứ sập-lặp không được sửa bằng khởi động lại mạnh hơn; một thứ gì đó thực sự sai. systemd bắt stdout/stderr, nên:

systemctl status mybot          # lên hay xuống, mã thoát cuối
journalctl -u mybot -n 100      # các log gần đây + lỗi nó chết vì đó
journalctl -u mybot -f          # theo dõi trực tiếp

Nguyên nhân gần như luôn ngay đó: một biến môi trường thiếu, một ngoại lệ không được xử lý, một timeout API, một lần bị giết vì OOM. Sửa cái đóRestart=always là một tấm lưới an toàn, không phải một cách chữa một lỗi thật.

Mẹo: nếu các log cho thấy bot bị giết vì bộ nhớ, bạn đã vượt quá cỗ máy — xem hướng dẫn chọn kích cỡ.

Khi nào tmux hoặc pm2 hợp lý thay vào đó

systemd không phải câu trả lời duy nhất, chỉ là mặc định tốt nhất:

Cho một bot hoặc agent luôn-bật đơn, systemd là thứ đơn giản nhất thực sự hoạt động — nó đã trên máy chủ, không cần công cụ thêm, và làm khởi động lại, khởi động-lúc-boot và log ngay.

Kết luận trung thực

Thời gian hoạt động không phải về một máy chủ lớn hơn hay nhiều kỷ luật hơn — nó về việc không gắn tiến trình của bạn với laptop của bạn. Bọc nó trong một unit systemd với Restart=alwaysenable, và kiểm tra journalctl khi có gì đó sai. Làm điều đó một lần và bot của bạn ở lại lên dù bạn đang xem hay ngủ. (Cỗ máy mới? Khóa nó lại trước — một bot 24/7 cũng là một mục tiêu 24/7.)


Cần nơi để chạy nó? Một gói Nano ($3/tháng) giữ một bot sống 24/7 — systemd làm phần còn lại.

FAQ

Vì sao bot của tôi dừng khi tôi đóng SSH?

Vì bạn khởi động nó bên trong phiên SSH của bạn, nên nó gắn với phiên đó và chết khi bạn ngắt kết nối. Cách sửa là chạy nó như một dịch vụ nền độc lập với đăng nhập của bạn — systemd là cách sạch, tmux là cách nhanh.

Làm sao tự khởi động lại một bot khi nó sập?

Chạy nó như một dịch vụ systemd với Restart=always và một độ trễ RestartSec nhỏ. systemd rồi khởi chạy lại tiến trình trong vài giây sau bất kỳ lần sập nào, vô thời hạn, không cần trông trẻ. Một dòng đó là khác biệt giữa 'nó chết lúc 4 giờ sáng' và 'nó chớp một cái và phục hồi.'

Làm sao làm một bot khởi động tự động sau một lần khởi động lại?

systemctl enable dịch vụ của bạn. 'enable' nối nó khởi động lúc boot, 'start' chạy nó bây giờ — làm cả hai (systemctl enable --now). Sau bất kỳ lần khởi động lại nào, bot trở lại một mình mà không cần bạn đăng nhập.

systemd hay pm2 hay tmux — tôi nên dùng cái nào?

systemd cho bất cứ gì thật và tồn tại lâu: nó xử lý khởi động lại, khởi động-lúc-boot và log một cách native, không công cụ thêm. tmux tuyệt cho một lần kiểm tra nhanh hoặc xem một lần chạy tương tác. pm2 hợp lý nếu bạn sống trong Node và muốn dashboard của nó, nhưng nó là một thứ nữa để giữ chạy. Cho một bot luôn-bật đơn, systemd thắng về sự đơn giản.

Làm sao tôi thấy vì sao bot của tôi cứ sập?

journalctl -u yourbot -n 100 cho thấy các log gần đây và lỗi nó chết vì đó; thêm -f để theo dõi trực tiếp. Đây thường là nơi nguyên nhân thật ẩn — một biến env thiếu, một ngoại lệ không được xử lý, một timeout API. Sửa cái đó, đừng chỉ khởi động lại một cách mù quáng.

← Quay lại blogXem gói & giá →

Bình luận

Chưa có bình luận nào. Hãy là người đầu tiên.

Để lại bình luận

Bình luận được kiểm duyệt trước khi hiển thị.