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 và & 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:
Restart=always— bot sập, systemd đưa nó trở lại trong 5 giây. Cái chết 4 giờ sáng đó trở thành một cái chớp 5 giây không ai để ý.enable— nó khởi động lại sau một lần khởi động lại, một mình. Không "ồ, máy chủ khởi động lại và tôi quên khởi chạy lại mọi thứ."
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:
- tmux — hoàn hảo cho một lần kiểm tra nhanh hoặc xem một tiến trình tương tác. Chạy, detach, reattach sau. Nhưng nó sẽ không khởi động lại khi sập hay sống sót qua một lần khởi động lại, nên nó không cho production.
- pm2 — hợp lý nếu bạn đã ở trong thế giới Node và muốn dashboard tiến trình của nó. Điểm bắt: pm2 tự nó là một tiến trình bạn giờ phải giữ sống (thường... qua systemd). Cho một bot, đó là một lớp bạn không cần.
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=always và enable, 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.
Bình luận
Chưa có bình luận nào. Hãy là người đầu tiên.