რატომ ჩერდება ჩემი ბოტი, როცა SSH-ს ვხურავ?

რადგან ის თქვენს SSH სესიაში გაუშვით, ასე რომ ის მიბმულია ამ სესიაზე და კვდება, როცა თიშავთ. გამოსავალი არის მისი გაშვება ფონურ სერვისად, რომელიც თქვენი login-ისგან დამოუკიდებელია — systemd სუფთა გზაა, tmux სწრაფი გზა.

როგორ გავაკეთო ბოტის ავტო-რესტარტი crash-ისას?

გაუშვით ის systemd სერვისად Restart=always-ითა და პატარა RestartSec დაყოვნებით. systemd შემდეგ ხელახლა უშვებს პროცესს ნებისმიერი crash-იდან წამებში, განუსაზღვრელად, ძიძობის გარეშე. ის ერთი ხაზი განსხვავებაა „ის მოკვდა ღამის 4 საათზე“-სა და „ის ხახუნდა და აღდგა“-ს შორის.

როგორ გავაკეთო, რომ ბოტი ავტომატურად ჩაირთოს გადატვირთვის შემდეგ?

systemctl enable თქვენი სერვისი. „enable“ აბამს მას ჩატვირთვისას ჩასართავად, „start“ უშვებს მას ახლა — გააკეთეთ ორივე (systemctl enable --now). ნებისმიერი გადატვირთვის შემდეგ ბოტი თავად ბრუნდება თქვენი შესვლის გარეშე.

systemd თუ pm2 თუ tmux — რომელი გამოვიყენო?

systemd ყველაფრისთვის, რაც ნამდვილი და გრძელვადიანია: ის უმკლავდება რესტარტს, boot-start-სა და logging-ს ბუნებრივად, დამატებითი ხელსაწყოს გარეშე. tmux შესანიშნავია სწრაფი ტესტისთვის ან ინტერაქტიული გაშვების საყურებლად. pm2 გონივრულია, თუ Node-ში ცხოვრობთ და მისი dashboard გინდათ, მაგრამ ის კიდევ ერთი რამაა გასაშვებად. ერთი ყოველთვის-ჩართული ბოტისთვის, systemd იმარჯვებს სიმარტივით.

როგორ დავინახო, რატომ crash-ს აკეთებს ჩემი ბოტი?

journalctl -u yourbot -n 100 აჩვენებს ბოლო log-ებსა და შეცდომას, რომელზეც ის მოკვდა; დაამატეთ -f ცოცხლად სამყურებლად. აქ ჩვეულებრივ იმალება ნამდვილი მიზეზი — გამოტოვებული env var, დაუმუშავებელი exception, API timeout. გაასწორეთ ეს, ნუ გადატვირთავთ ბრმად.

შეინარჩუნეთ ბოტი გაშვებული 24/7 VPS-ზე (რომ ის არასოდეს ჩუმად მოკვდეს)

ორი გზაა, რომლითაც ბოტი „არ მუშაობს“ სერვერზე. აშკარა: ის ჩერდება იმ წამს, როცა SSH-ს ხურავთ. მზაკვრული: ის კარგად მუშაობს ორ დღეს, crash-ს აკეთებს ღამის 4 საათზე რაღაც დაუმუშავებელ შეცდომაზე, და საათების შემდეგ იგებთ, როცა ვინმე იკითხავს, რატომ არის ის გათიშული. ორივეს იგივე გამოსავალი აქვს, და ეს არ არის „გახსოვდეს მისი რესტარტი“ — ეს არის საქმის გადაცემა systemd-ისთვის, რომელიც ინახავს ყველაფერს ჩართულს, რომ თქვენ არ მოგიწიოთ.

რატომ კვდება ის, როცა გამოხვალთ

თუ გაუშვით ის python bot.py-ით თქვენს SSH სესიაში, პროცესი ამ სესიის შვილია. დახურეთ სესია, პროცესი მასთან ერთად მიდის. nohup და & ფარავენ ამას, მაგრამ არ გაძლევენ restart-on-crash-სა და start-on-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 — ბოტი crash-ს აკეთებს, systemd აბრუნებს მას 5 წამში. ის ღამის 4 საათის სიკვდილი ხდება 5-წამიანი ხახუნი, რომელსაც არავინ ამჩნევს.
enable — ის კვლავ ჩაირთვება გადატვირთვის შემდეგ, თავად. არავითარი „ოჰ, სერვერი გადაიტვირთა და დამავიწყდა ყველაფრის ხელახლა გაშვება“.

როცა ის მაინც ცუდად იქცევა — წაიკითხეთ log-ები

ბოტი, რომელიც 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, დაუმუშავებელი exception, API timeout, OOM kill. გაასწორეთ ეს — Restart=always უსაფრთხოების ბადეა, არა ნამდვილი bug-ის მკურნალობა.

რჩევა: თუ log-ები აჩვენებს, რომ ბოტი მეხსიერებისთვის იკვლება, box-ს გადააჭარბეთ — შეამოწმეთ ზომის გზამკვლევი.

როცა tmux ან pm2 აზრს იძენს ამის ნაცვლად

systemd არ არის ერთადერთი პასუხი, უბრალოდ საუკეთესო ნაგულისხმევი:

tmux — სრულყოფილი სწრაფი ტესტისთვის ან ინტერაქტიული პროცესის საყურებლად. გაუშვით, გამოეყავით, ხელახლა მიაერთდით მოგვიანებით. მაგრამ ის არ გააკეთებს restart-ს crash-ზე და არ გადარჩება გადატვირთვას, ასე რომ ის არ არის production-ისთვის.
pm2 — გონივრული, თუ უკვე Node სამყაროში ხართ და მისი პროცესის dashboard გინდათ. ხაფანგი: pm2 თავად არის პროცესი, რომელიც ახლა უნდა შეინარჩუნოთ ცოცხლად (ჩვეულებრივ... systemd-ით). ერთი ბოტისთვის ეს ფენა, რომელიც არ გჭირდებათ.

ერთი ყოველთვის-ჩართული ბოტისთვის ან აგენტისთვის, systemd არის ყველაზე მარტივი რამ, რომელიც რეალურად მუშაობს — ის უკვე სერვერზეა, დამატებით ხელსაწყოს არ საჭიროებს და აკეთებს restart-ს, boot-start-სა და logging-ს კოლოფიდანვე.

გულწრფელი დასკვნა

Uptime არ არის უფრო დიდ სერვერზე ან მეტ დისციპლინაზე — ის არის თქვენი პროცესის laptop-თან არ-მიბმაზე. გახვიეთ ის systemd unit-ში Restart=always-ითა და enable-ით და შეამოწმეთ journalctl, როცა რამე ვერ არის. გააკეთეთ ეს ერთხელ და თქვენი ბოტი ჩართული რჩება, უყურებთ თუ იძინებთ. (ახალი box? ჯერ დაბლოკეთ ის — 24/7 ბოტი ასევე 24/7 სამიზნეა.)

გჭირდებათ სადმე მისი გასაშვები? Nano ტარიფი ($3/თვე) ინახავს ბოტს ცოცხლად 24/7 — systemd აკეთებს დანარჩენს.