یک ربات را به‌صورت شبانه‌روزی روی VPS فعال نگه دارید (تا هرگز بی‌صدا نمیرد)

یک ربات به دو شکل روی سرور «کار نمی‌کند». شکل آشکار: لحظه‌ای که SSH را می‌بندید متوقف می‌شود. شکل موذی: دو روز خوب کار می‌کند، ساعت ۴ بامداد روی یک خطای مدیریت‌نشده کرش می‌کند، و ساعت‌ها بعد که کسی می‌پرسد چرا قطع است می‌فهمید. هر دو یک راه‌حل دارند، و آن «یادت باشد ری‌استارتش کنی» نیست — سپردن کار به systemd است، که چیزها را بالا نگه می‌دارد تا شما مجبور نباشید.

چرا وقتی خارج می‌شوید می‌میرد

اگر آن را با python bot.py در نشست SSH خود اجرا کردید، فرایند فرزندِ آن نشست است. نشست را ببندید، فرایند هم با آن می‌رود. nohup و & این را ماست‌مالی می‌کنند، اما نه ری‌استارت هنگام کرش به شما می‌دهند و نه شروع در بوت — پس مسئله کوچک را حل کرده و بزرگ را نگه داشته‌اید.

راه‌حل واقعی: یک سرویس systemd

کل ماجرا همین است. فایل /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

دو خط بار اصلی را به دوش می‌کشند:

• Restart=always — ربات کرش می‌کند، ‏systemd ظرف ۵ ثانیه برش می‌گرداند. آن مرگ ساعت ۴ بامداد به یک قطعیِ ۵ ثانیه‌ای تبدیل می‌شود که کسی متوجهش نمی‌شود.
• enable — بعد از ری‌بوت خودش دوباره شروع می‌شود. دیگر «آه، سرور ری‌استارت شد و من یادم رفت همه‌چیز را دوباره راه بیندازم» نیست.

وقتی هنوز بدرفتاری می‌کند — لاگ‌ها را بخوانید

رباتی که مدام در حلقه کرش می‌افتد با محکم‌تر ری‌استارت‌کردن درست نمی‌شود؛ چیزی واقعاً اشکال دارد. systemd خروجی stdout/stderr را ثبت می‌کند، پس:

systemctl status mybot          # بالا یا پایین، آخرین کد خروج
journalctl -u mybot -n 100      # لاگ‌های اخیر + خطایی که رویش مرد
journalctl -u mybot -f          # دنبال‌کردن زنده

علت تقریباً همیشه همان‌جاست: یک متغیر محیطی گمشده، یک استثنای مدیریت‌نشده، یک timeout در API، یک OOM kill. آن را درست کنید — Restart=always یک تور ایمنی است، نه درمان یک باگ واقعی.

نکته: اگر لاگ‌ها نشان می‌دهند ربات به‌خاطر حافظه کشته می‌شود، از سرور بزرگ‌تر شده‌اید — راهنمای اندازه‌گیری را ببینید.

چه زمانی به‌جایش tmux یا pm2 منطقی است

systemd تنها پاسخ نیست، فقط بهترین پیش‌فرض است:

• tmux — برای یک تست سریع یا تماشای یک فرایند تعاملی عالی است. اجرا کنید، جدا شوید، بعداً دوباره وصل شوید. اما هنگام کرش ری‌استارت نمی‌کند و از ری‌بوت جان سالم به در نمی‌برد، پس برای محیط تولید نیست.
• pm2 — اگر همین حالا در دنیای Node هستید و داشبورد فرایندش را می‌خواهید معقول است. نکته‌اش: pm2 خودش فرایندی است که حالا باید زنده نگهش دارید (معمولاً... با systemd). برای یک ربات، این لایه‌ای است که به آن نیازی ندارید.

برای یک ربات یا عامل تک و همیشه‌فعال، systemd ساده‌ترین چیزی است که واقعاً کار می‌کند — همین حالا روی سرور هست، به ابزار اضافی نیاز ندارد، و ری‌استارت، شروع در بوت و لاگ‌گیری را از همان ابتدا انجام می‌دهد.

خلاصه صادقانه کلام

آپ‌تایم درباره یک سرور بزرگ‌تر یا انضباط بیشتر نیست — درباره گره‌نزدن فرایندتان به لپ‌تاپ‌تان است. آن را در یک unit از systemd با Restart=always و enable بپیچید، و وقتی چیزی خطاست journalctl را چک کنید. این را یک بار انجام دهید و ربات‌تان چه بیدار باشید چه خواب، بالا می‌ماند. (سرور تازه؟ اول محکمش کنید — یک ربات شبانه‌روزی، یک هدف شبانه‌روزی هم هست.)

جایی برای اجرایش می‌خواهید؟ یک پلن Nano (‏۳ دلار در ماه) یک ربات را به‌صورت شبانه‌روزی زنده نگه می‌دارد — بقیه‌اش را systemd انجام می‌دهد.