एक सर्वर पर एक बॉट के "काम न करने" के दो तरीक़े हैं। स्पष्ट वाला: यह उस पल रुक जाता है जब आप SSH बंद करते हैं। चालाक वाला: यह दो दिन ठीक चलता है, किसी अनहैंडल्ड त्रुटि पर 4 बजे क्रैश होता है, और आपको घंटों बाद पता चलता है जब कोई पूछता है कि यह डाउन क्यों है। दोनों का वही समाधान है, और यह "इसे रीस्टार्ट करना याद रखें" नहीं है — यह काम systemd को सौंपना है, जो चीज़ों को चालू रखता है ताकि आपको न रखना पड़े।
लॉग आउट पर यह क्यों मरता है
अगर आपने इसे अपने SSH सत्र में python bot.py से लॉन्च किया, प्रोसेस उस सत्र का एक चाइल्ड है। सत्र बंद करें, प्रोसेस उसके साथ जाता है। nohup और & इसे ढकते हैं, पर वे आपको कोई रीस्टार्ट-ऑन-क्रैश और कोई स्टार्ट-ऑन-बूट नहीं देते — तो आपने छोटी समस्या हल की और बड़ी रखी।
असली समाधान: एक 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— यह रीबूट के बाद फिर शुरू होता है, अपने दम पर। कोई "ओह, सर्वर रीस्टार्ट हुआ और मैं सब कुछ फिर लॉन्च करना भूल गया" नहीं।
जब यह अब भी बदमाशी कर रहा हो — लॉग पढ़ें
एक बॉट जो क्रैश-लूप करता रहता है, ज़्यादा ज़ोर से रीस्टार्ट करने से ठीक नहीं होता; सचमुच कुछ ग़लत है। systemd stdout/stderr कैप्चर करता है, तो:
systemctl status mybot # चालू या डाउन, आख़िरी exit code
journalctl -u mybot -n 100 # हाल के लॉग + वह त्रुटि जिस पर यह मरा
journalctl -u mybot -f # लाइव फ़ॉलो
कारण लगभग हमेशा ठीक वहीं है: एक ग़ायब एनवायरनमेंट वेरिएबल, एक अनहैंडल्ड अपवाद, एक API टाइमआउट, एक OOM किल। उसे ठीक करें — Restart=always एक सुरक्षा जाल है, एक असली बग का इलाज नहीं।
सुझाव: अगर लॉग बॉट को मेमोरी के लिए मारा जाता दिखाएँ, आप बॉक्स से बड़े हो गए हैं — साइज़िंग गाइड देखें।
कब बजाय इसके tmux या pm2 मायने रखते हैं
systemd एकमात्र जवाब नहीं, बस सबसे अच्छा डिफ़ॉल्ट:
- tmux — एक झटपट परीक्षण या एक इंटरैक्टिव प्रोसेस देखने के लिए उत्तम। चलाएँ, अलग करें, बाद में फिर जुड़ें। पर यह क्रैश पर रीस्टार्ट नहीं होगा या एक रीबूट नहीं झेलेगा, तो यह प्रोडक्शन के लिए नहीं।
- pm2 — उचित अगर आप पहले से Node दुनिया में हैं और उसका प्रोसेस डैशबोर्ड चाहते हैं। पेच: pm2 ख़ुद एक प्रोसेस है जिसे अब आपको ज़िंदा रखना है (आमतौर पर... systemd के ज़रिए)। एक बॉट के लिए, वह एक परत है जो आपको नहीं चाहिए।
एक अकेले हरदम-चालू बॉट या एजेंट के लिए, systemd सबसे सरल चीज़ है जो असल में काम करती है — यह पहले से सर्वर पर है, कोई अतिरिक्त टूलिंग नहीं चाहिए, और रीस्टार्ट, बूट-स्टार्ट और लॉगिंग बॉक्स से बाहर करता है।
ईमानदार लब्बोलुआब
अपटाइम एक बड़े सर्वर या ज़्यादा अनुशासन के बारे में नहीं — यह अपनी प्रोसेस को अपने लैपटॉप से न बाँधने के बारे में है। इसे Restart=always और enable वाले एक systemd यूनिट में लपेटें, और जब कुछ गड़बड़ हो तो journalctl जाँचें। यह एक बार करें और आपका बॉट चालू रहता है चाहे आप देख रहे हों या सो रहे हों। (नया बॉक्स? पहले इसे बंद करें — एक 24/7 बॉट एक 24/7 लक्ष्य भी है।)
इसे चलाने के लिए कहीं चाहिए? एक Nano प्लान ($3/माह) एक बॉट को 24/7 ज़िंदा रखता है — systemd बाक़ी करता है।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।