Ține un bot pornit 24/7 pe un VPS (ca să nu moară niciodată pe tăcute)

15 iun. 2026 · 3 min de citit · EQVPS Team

Un bot „nu merge” pe un server în două feluri. Felul evident: se oprește în secunda în care închizi SSH. Felul perfid: merge bine două zile, pică la 4 dimineața din cauza unei erori netratate și afli după câteva ore, când te întreabă cineva de ce nu răspunde. Ambele au aceeași soluție, și nu e „ține minte să-l repornești” — e să-i dai treaba lui systemd, care ține lucrurile pornite ca să nu trebuiască s-o faci tu.

De ce moare când ieși din sesiune

Dacă l-ai pornit cu python bot.py în sesiunea SSH, procesul e un copil al acelei sesiuni. Închizi sesiunea, procesul pleacă odată cu ea. nohup și & acoperă asta, dar nu-ți dau nici repornire după căderi, nici pornire la boot — deci ai rezolvat problema mică și ai păstrat-o pe cea mare.

Soluția reală: un serviciu systemd

Asta e tot. Creează /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

Două linii fac munca grea:

Restart=always — botul pică, systemd îl readuce în 5 secunde. Moartea de la 4 dimineața devine o clipire de 5 secunde pe care n-o observă nimeni.
enable — pornește din nou singur după o repornire. Fără „a, serverul a repornit și am uitat să relansez totul”.

Când tot se poartă urât — citește logurile

Un bot care intră mereu în bucla de căderi nu se repară repornindu-l mai tare; chiar e ceva în neregulă. systemd capturează stdout/stderr, așa că:

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

Cauza e aproape întotdeauna chiar acolo: o variabilă de mediu lipsă, o excepție netratată, un timeout de API, o oprire din lipsă de memorie. Repar-o pe aceea — Restart=always e o plasă de siguranță, nu un leac pentru un bug real.

Sfat: dacă logurile arată că botul e oprit din lipsă de memorie, ai depășit mașina — verifică ghidul de dimensionare.

Când se potrivesc în schimb tmux sau pm2

systemd nu e singurul răspuns, doar cea mai bună alegere implicită:

tmux — perfect pentru un test rapid sau ca să urmărești un proces interactiv. Rulezi, te detașezi, te reatașezi mai târziu. Dar nu repornește după căderi și nu supraviețuiește unei reporniri, deci nu e pentru producție.
pm2 — rezonabil dacă ești deja în lumea Node și vrei panoul lui de procese. Capcana: pm2 e el însuși un proces pe care acum trebuie să-l ții în viață (de obicei... prin systemd). Pentru un singur bot, e un strat de care nu ai nevoie.

Pentru un singur bot sau agent mereu pornit, systemd e cel mai simplu lucru care chiar funcționează — e deja pe server, nu cere unelte în plus și face din prima repornirea, pornirea la boot și logurile.

Concluzia cinstită

Disponibilitatea nu ține de un server mai mare sau de mai multă disciplină — ține de a nu-ți lega procesul de laptop. Pune-l într-o unitate systemd cu Restart=always și enable și verifică journalctl când ceva nu e în regulă. Fă asta o dată și botul tău rămâne pornit, fie că te uiți, fie că dormi. (Mașină nouă? Închide-o întâi — un bot 24/7 e și o țintă 24/7.)

Ai nevoie de un loc unde să-l rulezi? Un plan Nano ($3/lună) ține un bot în viață 24/7 — systemd face restul.

Întrebări frecvente

De ce se oprește botul meu când închid SSH?

Pentru că l-ai pornit în sesiunea SSH, așa că e legat de ea și moare când te deconectezi. Soluția e să-l rulezi ca serviciu de fundal, independent de autentificarea ta — systemd e calea curată, tmux e calea rapidă.

Cum repornesc automat un bot când pică?

Rulează-l ca serviciu systemd cu Restart=always și o mică întârziere RestartSec. systemd relansează apoi procesul în câteva secunde după orice cădere, la nesfârșit, fără supraveghere. Linia asta singură e diferența dintre „a murit la 4 dimineața” și „a clipit și și-a revenit”.

Cum fac un bot să pornească automat după o repornire?

Cu systemctl enable pentru serviciul tău. „enable” îl leagă de pornirea la boot, „start” îl rulează acum — fă-le pe amândouă (systemctl enable --now). După orice repornire, botul revine singur, fără să te autentifici.

systemd, pm2 sau tmux — pe care să-l folosesc?

systemd pentru orice e real și de lungă durată: se ocupă nativ de repornire, de pornirea la boot și de loguri, fără unelte în plus. tmux e excelent pentru un test rapid sau ca să urmărești o rulare interactivă. pm2 e rezonabil dacă trăiești în Node și vrei panoul lui, dar e încă un lucru de ținut pornit. Pentru un singur bot mereu pornit, systemd câștigă prin simplitate.

Cum văd de ce tot pică botul meu?

journalctl -u numele-botului -n 100 îți arată logurile recente și eroarea de care a murit; adaugă -f ca să le urmărești în timp real. De obicei acolo se ascunde cauza reală — o variabilă de mediu lipsă, o excepție netratată, un timeout de API. Repar-o pe aceea, nu reporni orbește.

Comentarii

Încă nu există comentarii. Fii primul.