EQVPS

ایک VPS پر ایک bot کو 24/7 چلتا رکھیں (تاکہ یہ کبھی خاموشی سے نہ مرے)

Jun 15, 2026 · 3 min read · EQVPS Team

ایک سرور پر ایک bot کے "کام نہ کرنے" کے دو طریقے ہیں۔ واضح والا: یہ اُس لمحے رکتا ہے جب آپ SSH بند کریں۔ چالاک والا: یہ دو دن خوب چلتا ہے، رات 4 بجے کسی unhandled error پر کریش ہوتا ہے، اور آپ کو گھنٹوں بعد پتہ چلتا ہے جب کوئی پوچھتا ہے یہ کیوں down ہے۔ دونوں کا وہی حل ہے، اور یہ "اسے restart کرنا یاد رکھیں" نہیں — یہ کام systemd کو دینا ہے، جو چیزیں اوپر رکھتا ہے تاکہ آپ کو نہ رکھنی پڑیں۔

یہ log out کرنے پر کیوں مرتا ہے

اگر آپ نے اسے اپنے SSH سیشن میں python bot.py سے چالو کیا، تو process اُس سیشن کا ایک child ہے۔ سیشن بند کریں، process اس کے ساتھ چلا جاتا ہے۔ 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

دو لائنیں بھاری کام کر رہی ہیں:

جب یہ پھر بھی بدسلوکی کرے — logs پڑھیں

ایک bot جو کریش-loop کرتا رہتا ہے وہ زیادہ سختی سے restart کرنے سے ٹھیک نہیں ہوتا؛ کچھ دراصل غلط ہے۔ systemd stdout/stderr پکڑتا ہے، تو:

systemctl status mybot          # اوپر یا نیچے، آخری exit code
journalctl -u mybot -n 100      # حالیہ logs + وہ error جس پر یہ مرا
journalctl -u mybot -f          # live فالو کریں

وجہ تقریباً ہمیشہ بالکل وہیں ہوتی ہے: ایک غائب environment variable، ایک unhandled exception، ایک API timeout، ایک OOM kill۔ اسے ٹھیک کریں — Restart=always ایک حفاظتی جال ہے، ایک حقیقی bug کا علاج نہیں۔

ٹپ: اگر logs bot کو memory کے لیے kill ہوتا دکھائیں، تو آپ باکس سے بڑھ گئے ہیں — sizing گائیڈ دیکھیں۔

کب tmux یا pm2 اس کے بجائے سمجھ رکھتے ہیں

systemd واحد جواب نہیں، بس بہترین ڈیفالٹ:

ایک واحد ہمیشہ-آن bot یا agent کے لیے، systemd سب سے سادہ چیز ہے جو دراصل کام کرتی ہے — یہ پہلے ہی سرور پر ہے، کوئی اضافی tooling نہیں چاہیے، اور restart، boot-start اور logging out of the box کرتا ہے۔

ایماندار مختصر بات

Uptime ایک بڑے سرور یا زیادہ نظم کے بارے میں نہیں — یہ اپنے process کو اپنے لیپ ٹاپ سے نہ باندھنے کے بارے میں ہے۔ اسے Restart=always اور enable والے ایک systemd unit میں لپیٹیں، اور جب کچھ خراب ہو تو journalctl چیک کریں۔ یہ ایک بار کریں اور آپ کا bot اوپر رہتا ہے چاہے آپ دیکھ رہے ہوں یا سو رہے ہوں۔ (نیا باکس؟ اسے پہلے لاک کریں — ایک 24/7 bot ایک 24/7 ہدف بھی ہے۔)


اسے چلانے کو کہیں چاہیے؟ ایک Nano پلان ($3/ماہ) ایک bot کو 24/7 زندہ رکھتا ہے — باقی systemd کرتا ہے۔

FAQ

میرا bot SSH بند کرنے پر کیوں رک جاتا ہے؟

کیونکہ آپ نے اسے اپنے SSH سیشن کے اندر شروع کیا، تو یہ اُس سیشن سے بندھا ہے اور آپ کے disconnect کرنے پر مر جاتا ہے۔ حل اسے ایک background سروس کے طور پر چلانا ہے جو آپ کے login سے آزاد ہو — systemd صاف طریقہ ہے، tmux فوری طریقہ۔

میں ایک bot کریش ہونے پر auto-restart کیسے کروں؟

اسے Restart=always اور ایک چھوٹی RestartSec تاخیر والی ایک systemd سروس کے طور پر چلائیں۔ systemd پھر کسی بھی کریش کے سیکنڈوں میں process کو دوبارہ چالو کرتا ہے، بلا حد، بغیر نگرانی کے۔ وہ ایک لائن 'یہ رات 4 بجے مر گیا' اور 'یہ ایک لمحہ رکا اور بحال ہو گیا' کے بیچ فرق ہے۔

میں ایک bot کو ایک ری بوٹ کے بعد خودبخود شروع کیسے کراؤں؟

اپنی سروس systemctl enable کریں۔ 'enable' اسے boot پر شروع ہونے کو جوڑتا ہے، 'start' اسے اب چلاتا ہے — دونوں کریں (systemctl enable --now)۔ کسی بھی ری بوٹ کے بعد، bot آپ کے log in کیے بغیر خود واپس آتا ہے۔

systemd یا pm2 یا tmux — میں کون سا استعمال کروں؟

کسی بھی حقیقی اور دیرپا چیز کے لیے systemd: یہ restart، boot-start اور logging کو مقامی طور پر سنبھالتا ہے، کوئی اضافی tooling نہیں۔ tmux ایک فوری test یا ایک interactive run دیکھنے کو بہترین ہے۔ pm2 معقول ہے اگر آپ Node میں رہتے اور اس کا dashboard چاہتے ہوں، لیکن یہ چلتا رکھنے کو ایک اور چیز ہے۔ ایک واحد ہمیشہ-آن bot کے لیے، systemd سادگی پر جیتتا ہے۔

میں کیسے دیکھوں کہ میرا bot کیوں کریش ہوتا رہتا ہے؟

journalctl -u yourbot -n 100 حالیہ logs اور وہ error دکھاتا ہے جس پر یہ مرا؛ live فالو کرنے کو -f جوڑیں۔ عموماً یہیں اصل وجہ چھپی ہوتی ہے — ایک غائب env var، ایک unhandled exception، ایک API timeout۔ اسے ٹھیک کریں، بس اندھا restart نہ کریں۔

← Back to blogSee plans & pricing →

تبصرے

ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔

ایک تبصرہ چھوڑیں

تبصرے ظاہر ہونے سے پہلے moderate کیے جاتے ہیں۔