Jaga bot berjalan 24/7 di VPS (agar tidak pernah mati diam-diam)

Ada dua cara sebuah bot "tidak bekerja" di server. Yang jelas: ia berhenti detik Anda menutup SSH. Yang licik: ia berjalan baik selama dua hari, crash jam 4 pagi karena suatu error tak-tertangani, dan Anda baru tahu berjam-jam kemudian saat seseorang bertanya mengapa ia mati. Keduanya punya perbaikan yang sama, dan itu bukan "ingat untuk restart" — melainkan menyerahkan tugasnya ke systemd, yang menjaga hal tetap menyala agar Anda tidak perlu.

Mengapa ia mati saat Anda keluar

Jika Anda meluncurkannya dengan python bot.py di sesi SSH Anda, proses itu adalah anak dari sesi itu. Tutup sesinya, prosesnya ikut. nohup dan & menutupi ini, tapi mereka tidak memberi Anda restart-saat-crash dan mulai-saat-boot — jadi Anda telah memecahkan masalah kecil dan mempertahankan yang besar.

Perbaikan sebenarnya: layanan systemd

Ini keseluruhannya. Buat /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

Dua baris melakukan pekerjaan berat:

• Restart=always — bot crash, systemd mengembalikannya dalam 5 detik. Kematian jam 4 pagi itu menjadi kedipan 5 detik yang tak seorang pun menyadari.
• enable — ia mulai lagi setelah reboot, sendiri. Tanpa "oh, servernya restart dan saya lupa meluncurkan ulang semuanya".

Saat ia masih berulah — baca log-nya

Bot yang terus crash-loop tidak diperbaiki dengan restart lebih keras; ada sesuatu yang benar-benar salah. systemd menangkap stdout/stderr, jadi:

systemctl status mybot          # naik atau turun, kode keluar terakhir
journalctl -u mybot -n 100      # log terkini + error tempat ia mati
journalctl -u mybot -f          # ikuti langsung

Penyebabnya hampir selalu tepat di sana: variabel lingkungan yang hilang, eksepsi tak-tertangani, timeout API, pembunuhan OOM. Perbaiki itu — Restart=always adalah jaring pengaman, bukan obat untuk bug sungguhan.

Tip: jika log menunjukkan bot dibunuh karena memori, Anda telah melampaui mesinnya — periksa panduan penentuan ukuran.

Kapan tmux atau pm2 masuk akal sebagai gantinya

systemd bukan satu-satunya jawaban, hanya bawaan terbaik:

• tmux — sempurna untuk uji cepat atau mengawasi proses interaktif. Jalankan, lepas, sambung kembali nanti. Tapi ia tidak akan restart saat crash atau bertahan dari reboot, jadi bukan untuk produksi.
• pm2 — masuk akal jika Anda sudah di dunia Node dan ingin dasbor prosesnya. Pengecualiannya: pm2 sendiri adalah proses yang sekarang harus Anda jaga tetap hidup (biasanya... lewat systemd). Untuk satu bot, itu lapisan yang tidak Anda butuhkan.

Untuk satu bot selalu-aktif atau agen, systemd adalah hal paling sederhana yang benar-benar bekerja — ia sudah ada di server, tidak butuh perkakas tambahan, dan melakukan restart, mulai-saat-boot dan logging secara bawaan.

Kesimpulan jujur

Uptime bukan soal server lebih besar atau lebih banyak disiplin — melainkan soal tidak mengikat proses Anda ke laptop Anda. Bungkus dalam unit systemd dengan Restart=always dan enable, dan periksa journalctl saat ada yang tidak beres. Lakukan itu sekali dan bot Anda tetap menyala entah Anda mengawasi atau tidur. (Mesin baru? Kunci dulu — bot 24/7 juga target 24/7.)

Butuh tempat menjalankannya? Paket Nano ($3/bln) menjaga bot hidup 24/7 — systemd melakukan sisanya.