حرّ الصيف — كل شيء يذوب، حتى أسعارنا.−25%−25% على كل خطة سنوية، حتى 31 أغسطسعرض الخطط
EQVPS

أبقِ بوتًا يعمل على مدار الساعة على VPS (كي لا يموت بصمت أبدًا)

15 يونيو 2026 · 2 دقيقة قراءة · EQVPS Team

هناك طريقتان لا «يعمل» بهما بوت على خادم. الواضحة: يتوقّف اللحظة التي تُغلق فيها SSH. الماكرة: يعمل جيّدًا يومين، يتعطّل الرابعة فجرًا على خطأ غير معالَج، وتكتشف ذلك بعد ساعات حين يسأل أحد لماذا هو معطّل. لكليهما الحلّ نفسه، وهو ليس «تذكّر أن تُعيد تشغيله» — إنه تسليم المهمّة لـ systemd، الذي يُبقي الأشياء مشتغلة كي لا تضطرّ أنت.

لماذا يموت حين تسجّل الخروج

إن أطلقته بـ python bot.py في جلسة SSH، فالعملية ابنة تلك الجلسة. أغلق الجلسة، تذهب العملية معها. 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

سطران يقومان بالعمل الثقيل:

حين يظلّ يسيء التصرّف — اقرأ السجلّات

بوت يظلّ في حلقة تعطّل لا يُصلَح بإعادة تشغيل أقوى؛ شيء ما خطأ فعلًا. systemd يلتقط stdout/stderr، فـ:

systemctl status mybot          # مشتغل أم معطّل، آخر رمز خروج
journalctl -u mybot -n 100      # السجلّات الأخيرة + الخطأ الذي مات عليه
journalctl -u mybot -f          # متابعة حيّة

السبب تقريبًا دائمًا هناك: متغيّر بيئة مفقود، استثناء غير معالَج، انتهاء مهلة API، قتل نفاد ذاكرة. أصلح ذلكRestart=always شبكة أمان، لا علاج لخطأ حقيقي.

نصيحة: إن أظهرت السجلّات قتل البوت للذاكرة، فقد تجاوزت الصندوق — راجع دليل تحديد الحجم.

متى يكون tmux أو pm2 منطقيًا بدلًا

systemd ليس الجواب الوحيد، فقط الافتراضي الأفضل:

لبوت واحد دائم التشغيل أو وكيل، systemd هو أبسط ما يعمل فعلًا — إنه على الخادم أصلًا، لا يحتاج أدوات إضافية، ويقوم بإعادة التشغيل والبدء-عند-الإقلاع والتسجيل جاهزًا.

الخلاصة الصادقة

وقت التشغيل ليس عن خادم أكبر أو انضباط أكثر — إنه عن عدم ربط عمليتك بحاسوبك المحمول. غلّفه في وحدة systemd بـ Restart=always وenable، وافحص journalctl حين يختلّ شيء. افعل ذلك مرة ويبقى بوتك مشتغلًا سواء كنت تراقب أم نائمًا. (صندوق جديد؟ أحكِمه أولًا — بوت على مدار الساعة هو أيضًا هدف على مدار الساعة.)


تحتاج مكانًا لتشغيله؟ خطة Nano (3$ شهريًا) تُبقي بوتًا حيًّا على مدار الساعة — systemd يفعل الباقي.

الأسئلة الشائعة

لماذا يتوقّف بوتي حين أُغلق SSH؟

لأنك بدأته داخل جلسة SSH، فهو مربوط بتلك الجلسة ويموت حين تفصل. الحلّ تشغيله كخدمة خلفية مستقلّة عن دخولك — systemd هو الطريقة النظيفة، tmux هو الطريقة السريعة.

كيف أُعيد تشغيل بوت تلقائيًا عند التعطّل؟

شغّله كخدمة systemd بـ Restart=always وتأخير RestartSec صغير. عندها يُعيد systemd إطلاق العملية خلال ثوانٍ من أي عطل، إلى ما لا نهاية، بلا مجالسة. ذلك السطر الواحد هو الفرق بين «مات الرابعة فجرًا» و«ومض وتعافى».

كيف أجعل بوتًا يبدأ تلقائيًا بعد إعادة تشغيل؟

systemctl enable لخدمتك. «enable» يربطه للبدء عند الإقلاع، «start» يُشغّله الآن — افعل كليهما (systemctl enable --now). بعد أي إعادة تشغيل، يعود البوت من تلقاء نفسه دون تسجيل دخولك.

systemd أم pm2 أم tmux — أيّها أستخدم؟

systemd لأي شيء حقيقي طويل الأمد: يتولّى إعادة التشغيل والبدء-عند-الإقلاع والتسجيل أصيلًا، بلا أدوات إضافية. tmux رائع لاختبار سريع أو مراقبة تشغيل تفاعلي. pm2 معقول إن كنت تعيش في Node وتريد لوحته، لكنه شيء آخر تُبقيه يعمل. لبوت واحد دائم التشغيل، systemd يفوز على البساطة.

كيف أرى لماذا يظلّ بوتي يتعطّل؟

journalctl -u yourbot -n 100 يُظهر السجلّات الأخيرة والخطأ الذي مات عليه؛ أضف -f للمتابعة الحيّة. عادةً هنا يختبئ السبب الحقيقي — متغيّر بيئة مفقود، استثناء غير معالَج، انتهاء مهلة API. أصلح ذلك، لا تُعِد التشغيل بعمى فحسب.

← العودة إلى المدوّنة← الخطط والأسعار

التعليقات

لا تعليقات بعد. كن الأول.

اترك تعليقًا

تُراجَع التعليقات قبل ظهورها.