Κρατήστε ένα bot σε λειτουργία 24/7 σε VPS (ώστε να μην πεθαίνει ποτέ σιωπηλά)

Υπάρχουν δύο τρόποι με τους οποίους ένα bot «δεν λειτουργεί» σε έναν server. Ο προφανής: σταματά τη στιγμή που κλείνετε το SSH. Ο ύπουλος: τρέχει μια χαρά για δύο μέρες, κρασάρει στις 4 π.μ. σε κάποιο unhandled σφάλμα, και το μαθαίνετε ώρες αργότερα όταν κάποιος ρωτά γιατί είναι κάτω. Και οι δύο έχουν την ίδια λύση, και δεν είναι το «θυμήσου να το επανεκκινήσεις» — είναι η παράδοση της δουλειάς στο systemd, που κρατά τα πράγματα ενεργά ώστε να μη χρειάζεται εσείς.

Γιατί πεθαίνει όταν αποσυνδέεστε

Αν το εκκινήσατε με python bot.py στη συνεδρία SSH σας, η διεργασία είναι παιδί αυτής της συνεδρίας. Κλείστε τη συνεδρία, η διεργασία φεύγει μαζί της. Τα nohup και & καλύπτουν αυτό, αλλά δεν σας δίνουν restart-on-crash και start-on-boot — οπότε λύσατε το μικρό πρόβλημα και κρατήσατε το μεγάλο.

Η πραγματική λύση: ένα systemd service

Αυτό είναι όλο το πράγμα. Δημιουργήστε το /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 — το bot κρασάρει, το systemd το φέρνει πίσω σε 5 δευτερόλεπτα. Αυτός ο θάνατος στις 4 π.μ. γίνεται ένα 5-δευτερόλεπτο αναβόσβημα που κανείς δεν παρατηρεί.
• enable — ξεκινά ξανά μετά από επανεκκίνηση, μόνο του. Κανένα «α, ο server επανεκκίνησε και ξέχασα να ξαναεκκινήσω τα πάντα.»

Όταν εξακολουθεί να μη συμπεριφέρεται — διαβάστε τα logs

Ένα bot που συνεχίζει να crash-loop-άρει δεν διορθώνεται με σκληρότερη επανεκκίνηση· κάτι πραγματικά πάει στραβά. Το systemd συλλαμβάνει το stdout/stderr, οπότε:

systemctl status mybot          # up or down, last exit code
journalctl -u mybot -n 100      # recent logs + the error it died on
journalctl -u mybot -f          # follow live

Η αιτία είναι σχεδόν πάντα ακριβώς εκεί: ένα λείπον environment variable, μια unhandled exception, ένα API timeout, ένα OOM kill. Διορθώστε αυτό — το Restart=always είναι δίχτυ ασφαλείας, όχι θεραπεία για ένα πραγματικό bug.

Συμβουλή: αν τα logs δείχνουν το bot να σκοτώνεται για μνήμη, ξεπεράσατε το box — ελέγξτε τον οδηγό μεγέθους.

Πότε το tmux ή το pm2 βγάζουν νόημα αντ' αυτού

Το systemd δεν είναι η μόνη απάντηση, απλώς η καλύτερη προεπιλογή:

• tmux — τέλειο για μια γρήγορη δοκιμή ή παρακολούθηση μιας διαδραστικής διεργασίας. Τρέξτε, αποσυνδεθείτε, επανασυνδεθείτε αργότερα. Αλλά δεν θα επανεκκινήσει σε crash ή θα επιβιώσει επανεκκίνησης, οπότε δεν είναι για production.
• pm2 — λογικό αν είστε ήδη στον κόσμο του Node και θέλετε το process dashboard του. Το πρόβλημα: το pm2 είναι το ίδιο μια διεργασία που πρέπει τώρα να κρατάτε ζωντανή (συνήθως... μέσω systemd). Για ένα bot, αυτό είναι ένα επίπεδο που δεν χρειάζεστε.

Για ένα μεμονωμένο πάντα-ενεργό bot ή πράκτορα, το systemd είναι το απλούστερο πράγμα που πραγματικά λειτουργεί — είναι ήδη στον server, δεν χρειάζεται επιπλέον εργαλεία, και κάνει restart, boot-start και logging εκτός συσκευασίας.

Η έντιμη κατακλείδα

Το uptime δεν αφορά έναν μεγαλύτερο server ή περισσότερη πειθαρχία — αφορά το να μη δένετε τη διεργασία σας με το laptop σας. Τυλίξτε την σε ένα systemd unit με Restart=always και enable, και ελέγχετε το journalctl όταν κάτι πάει στραβά. Κάντε το μία φορά και το bot σας μένει ενεργό είτε παρακολουθείτε είτε κοιμάστε. (Νέο box; Κλειδώστε το πρώτα — ένα bot 24/7 είναι επίσης ένας στόχος 24/7.)

Χρειάζεστε κάπου να το τρέξετε; Ένα Nano πακέτο ($3/μήνα) κρατά ένα bot ζωντανό 24/7 — το systemd κάνει τα υπόλοιπα.