Дръж бот работещ 24/7 на VPS (така че никога да не умира тихо)

Има два начина, по които бот „не работи“ на сървър. Очевидният: спира в секундата, в която затвориш SSH. Коварният: работи добре два дни, срива се в 4 сутринта на някаква необработена грешка, а ти научаваш часове по-късно, когато някой попита защо е паднал. И двата имат едно и също решение, и то не е „помни да го рестартираш“ — то е да предадеш работата на systemd, който държи нещата включени, за да не се налага ти.

Защо умира, когато излезеш

Ако си го стартирал с python bot.py в SSH сесията си, процесът е дете на тази сесия. Затвори сесията, процесът си отива с нея. nohup и & замазват това, но не ти дават рестарт-при-срив и старт-при-boot — така че си решил малкия проблем и си запазил големия.

Реалното решение: 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 го връща за 5 секунди. Тази смърт в 4 сутринта става 5-секунден проблясък, който никой не забелязва.
• enable — стартира отново след рестарт, сам. Без „а, сървърът се рестартира и забравих да пусна всичко наново.“

Когато все още се държи зле — прочети логовете

Бот, който продължава да прави crash-loop, не се поправя с по-силно рестартиране; нещо реално е сгрешено. systemd хваща stdout/stderr, така че:

systemctl status mybot          # включен или паднал, последен exit code
journalctl -u mybot -n 100      # скорошни логове + грешката, на която е умрял
journalctl -u mybot -f          # следи на живо

Причината почти винаги е точно там: липсваща environment променлива, необработено изключение, API timeout, OOM kill. Поправи това — Restart=always е предпазна мрежа, не лек за реален бъг.

Съвет: ако логовете показват, че ботът бива убит за памет, надраснал си машината — виж ръководството за оразмеряване.

Кога tmux или pm2 имат смисъл вместо това

systemd не е единственият отговор, само най-добрият избор по подразбиране:

• tmux — перфектен за бърз тест или гледане на интерактивен процес. Пусни, откачи, прикачи по-късно. Но няма да рестартира при срив или да преживее рестарт, така че не е за production.
• pm2 — разумен, ако вече си в Node света и искаш таблото му за процеси. Уловката: pm2 сам по себе си е процес, който сега трябва да държиш жив (обикновено... чрез systemd). За един бот това е слой, от който не се нуждаеш.

За единичен винаги включен бот или агент, systemd е най-простото нещо, което реално работи — вече е на сървъра, не се нуждае от допълнителен инструментариум и прави рестарт, старт-при-boot и логване извън кутията.

Честното заключение

Времето на работа не е за по-голям сървър или повече дисциплина — то е за това да не връзваш процеса си към лаптопа си. Увий го в systemd unit с Restart=always и enable, и проверявай journalctl, когато нещо не е наред. Направи това веднъж и ботът ти стои включен, независимо дали гледаш, или спиш. (Нова машина? Заключи я първо — винаги включен бот е и винаги включена цел.)

Нужно ти е къде да го пуснеш? Nano план ($3/месец) държи бот жив 24/7 — systemd прави останалото.