ایک سرور پر ایک 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
دو لائنیں بھاری کام کر رہی ہیں:
Restart=always— bot کریش ہوتا ہے، systemd اسے 5 سیکنڈ میں واپس لاتا ہے۔ وہ رات 4 بجے کی موت ایک 5-سیکنڈ کا لمحہ بن جاتی ہے جسے کوئی نوٹ نہیں کرتا۔enable— یہ ایک ری بوٹ کے بعد خود دوبارہ شروع ہوتا ہے۔ کوئی "اوہ، سرور restart ہوا اور میں سب دوبارہ چالو کرنا بھول گیا" نہیں۔
جب یہ پھر بھی بدسلوکی کرے — 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 واحد جواب نہیں، بس بہترین ڈیفالٹ:
- tmux — ایک فوری test یا ایک interactive process دیکھنے کو بہترین۔ چلائیں، detach کریں، بعد میں reattach کریں۔ لیکن یہ کریش پر restart نہیں کرے گا یا ایک ری بوٹ سے نہیں بچے گا، تو یہ production کے لیے نہیں۔
- pm2 — معقول اگر آپ پہلے ہی Node دنیا میں ہیں اور اس کا process dashboard چاہتے ہیں۔ پیچ: pm2 خود ایک process ہے جسے اب آپ کو زندہ رکھنا ہے (عموماً... systemd کے ذریعے)۔ ایک bot کے لیے، یہ ایک تہہ ہے جو آپ کو نہیں چاہیے۔
ایک واحد ہمیشہ-آن 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 کرتا ہے۔
تبصرے
ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔