تشخيص الخدمات التي تفشل بعد إعادة تشغيل السيرفر: شرح قراءة سجلات systemd وjournalctl خطوة بخطوة في 2026

تُعدّ الخدمات التي تفشل بعد إعادة تشغيل السيرفر من أكثر ما يربك مديري خوادم Linux. يُعد فشل إحدى الخدمات في العمل بعد إعادة تشغيل السيرفر من أكثر المشكلات التي يواجهها مسؤولو أنظمة Linux. فقد يعمل الموقع بصورة طبيعية لساعات أو أيام، لكن بعد تنفيذ Reboot يتوقف NGINX أو PHP-FPM أو Node.js أو MariaDB دون ظهور سبب واضح، مما يؤدي إلى تعطل الموقع أو ظهور أخطاء مثل 502 Bad Gateway أو 504 Gateway Timeout أو حتى رفض الاتصال بالكامل.

في مثل هذه الحالات، لا يكون الحل في إعادة تشغيل الخدمة بشكل عشوائي، بل في قراءة سجلات النظام وتحليلها لمعرفة السبب الحقيقي. وهنا يأتي دور systemd وأداة journalctl التي توفر معلومات دقيقة حول سبب فشل الخدمة أثناء الإقلاع أو أثناء التشغيل.

في هذا الدليل ستتعرف على الطريقة الصحيحة لتشخيص الخدمات المتوقفة بعد إعادة تشغيل السيرفر، وكيفية استخدام أوامر systemctl وjournalctl للوصول إلى سبب المشكلة بسرعة، مع شرح أشهر رسائل الخطأ وكيفية التعامل معها.

لماذا تتوقف بعض الخدمات بعد إعادة التشغيل؟

قد تتوقف الخدمة بعد إعادة تشغيل السيرفر لأسباب عديدة، من أبرزها:

ولفهم إدارة الخدمات وتفعيلها عند الإقلاع، راجع: الدليل الكامل لقراءة سجلات السيرفر (Server Logs): تشخيص أعطال NGINX وPM2 وsystemd باستخدام journalctl في 2026.

• عدم تفعيل الخدمة لتعمل تلقائيًا عند الإقلاع.
• خطأ في ملف إعدادات الخدمة.
• عدم توفر صلاحيات كافية.
• تعارض في المنافذ.
• فشل الاتصال بقاعدة البيانات.
• تلف أحد ملفات الإعداد.
• بدء الخدمة قبل جاهزية الشبكة.
• خطأ في مسار الملف التنفيذي أو التطبيق.

لذلك يجب دائمًا الاعتماد على السجلات بدلًا من التخمين.

التحقق من حالة الخدمة

ابدأ أولًا بمعرفة حالة الخدمة:

systemctl status nginx

أو:

systemctl status php8.3-fpm

أو:

systemctl status myapp

إذا كانت الخدمة تعمل ستظهر الحالة:

Active: active (running)

أما إذا ظهرت:

Active: failed

أو:

Active: inactive

فهذا يعني أن الخدمة لم تبدأ بنجاح، ويجب مراجعة السجلات لمعرفة السبب.

قراءة سجل الخدمة باستخدام journalctl

أفضل أمر لتشخيص أي خدمة هو:

وjournalctl هو الأداة الرسمية لقراءة سجلات systemd؛ للتوثيق راجع دليل journalctl الرسمي.

journalctl -u nginx

أو:

journalctl -u myapp

سيعرض جميع الرسائل التي سجلها systemd لهذه الخدمة منذ تشغيلها.

إذا أردت مشاهدة آخر السجلات فقط:

journalctl -u nginx -n 50

أما لمتابعة السجل بشكل مباشر أثناء إعادة تشغيل الخدمة:

journalctl -fu nginx

وهذا مفيد جدًا أثناء اختبار التعديلات.

قراءة سجلات آخر عملية إقلاع

إذا ظهرت المشكلة بعد إعادة تشغيل السيرفر مباشرة، استخدم:

journalctl -b

يعرض هذا الأمر جميع السجلات الخاصة بآخر عملية Boot، مما يساعد على اكتشاف الخدمات التي فشلت أثناء الإقلاع.

ولعرض أخطاء الإقلاع فقط:

journalctl -b -p err

عرض الخدمات التي تفشل بعد الإقلاع

يمكنك معرفة الخدمات التي لم تبدأ بنجاح باستخدام:

systemctl --failed

إذا ظهرت أسماء مثل:

• nginx
• mariadb
• php-fpm

فابدأ بفحص كل خدمة على حدة باستخدام systemctl status وjournalctl.

أشهر رسائل الخطأ ومعناها

Failed to start

تعني أن systemd حاول تشغيل الخدمة لكنه فشل بسبب خطأ في الإعدادات أو التطبيق.

Permission denied

تشير إلى أن الخدمة لا تمتلك الصلاحيات اللازمة للوصول إلى ملف أو مجلد معين.

No such file or directory

تعني أن المسار الموجود في إعدادات الخدمة غير صحيح أو أن الملف التنفيذي مفقود.

Address already in use

تعني أن المنفذ المطلوب مستخدم بالفعل من قبل خدمة أخرى.

يمكن التأكد من ذلك باستخدام:

ss -tlnp

Connection refused

غالبًا تعني أن التطبيق الخلفي متوقف أو لا يستمع على المنفذ المتوقع، وهو سبب شائع لظهور خطأ 502 Bad Gateway.

مراجعة سجلات NGINX

إذا كان الموقع لا يعمل رغم أن الخدمة تعمل، راجع سجل الأخطاء:

وإذا ظهر خطأ 502 نتيجة ذلك، راجع: حل مشكلة 502 Bad Gateway بعد إعادة تشغيل السيرفر (NGINX وPHP-FPM وNode.js): الدليل الكامل للتشخيص والإصلاح في 2026.

tail -f /var/log/nginx/error.log

ولعرض سجل الزيارات:

tail -f /var/log/nginx/access.log

ستجد فيهما معلومات مهمة حول أسباب فشل الطلبات أو مشاكل الاتصال بالتطبيق الخلفي.

تشخيص خدمات Node.js وPM2

إذا كنت تستخدم PM2، اعرض السجلات بواسطة:

ولربط التطبيق بالدومين عبر NGINX، راجع: شرح NGINX Reverse Proxy: كيف يربط الدومين بتطبيقك الداخلي باستخدام proxy_pass؟ الدليل الكامل 2026.

pm2 logs

ولعرض سجل تطبيق معين:

pm2 logs app-name

إذا كان التطبيق يتوقف بعد إعادة التشغيل، تأكد من تنفيذ:

pm2 save

ثم:

pm2 startup

حتى يتم تشغيله تلقائيًا مع إقلاع النظام.

خطوات تشخيص احترافية

عند توقف أي خدمة بعد إعادة التشغيل، اتبع الترتيب التالي:

1. تحقق من حالة الخدمة:

systemctl status service-name

2. اقرأ سجل الخدمة:

journalctl -u service-name

3. اعرض الخدمات الفاشلة:

systemctl --failed

4. تحقق من المنافذ:

ss -tlnp

5. اختبر ملفات الإعداد الخاصة بالخدمة إذا كانت تدعم ذلك، مثل:

nginx -t

6. راجع سجل الأخطاء الخاص بالتطبيق أو الخادم.

بهذا الترتيب يمكنك الوصول إلى سبب المشكلة خلال دقائق بدلًا من إعادة تشغيل الخدمات بشكل عشوائي.

أفضل الممارسات

• فعّل جميع الخدمات المهمة باستخدام systemctl enable.
• اختبر ملفات الإعداد قبل إعادة تشغيل الخدمة.
• راقب السجلات بعد كل تحديث أو تغيير.
• استخدم journalctl بدلًا من الاعتماد على التخمين.
• احتفظ بنسخة احتياطية من ملفات الإعداد قبل تعديلها.
• راجع سجلات NGINX وPM2 وsystemd بانتظام لاكتشاف المشكلات مبكرًا.
• استخدم أدوات مراقبة مثل Uptime Kuma أو Netdata لتنبيهك عند توقف الخدمات.

الحل الدائم: تفعيل الخدمة عند الإقلاع

في أغلب الحالات تكون الخدمات التي تفشل بعد الإقلاع ببساطة غير مفعّلة للبدء التلقائي. فالخدمة قد تعمل الآن لأنك شغّلتها يدويًا، لكنها لن تعود بعد Reboot ما لم تُفعّلها.

systemctl enable nginx
systemctl enable --now myapp
systemctl is-enabled myapp

عندما يكون السبب ترتيب التبعيات

أحيانًا تبدأ الخدمة قبل جاهزية الشبكة أو قاعدة البيانات، فتفشل ثم تتوقف. الحل هو ضبط التبعيات في ملف الخدمة حتى تنتظر ما تحتاجه قبل البدء.

[Unit]
After=network-online.target mariadb.service
Requires=mariadb.service

إعادة المحاولة التلقائية عند الفشل

لتقليل أثر الخدمات التي تفشل مؤقتًا، اضبط إعادة المحاولة التلقائية بدل بقاء الخدمة متوقفة:

[Service]
Restart=always
RestartSec=5

قائمة تحقق سريعة

• هل الخدمة مفعّلة؟ systemctl is-enabled
• ما حالتها الآن؟ systemctl status
• ماذا يقول السجل؟ journalctl -u الخدمة -b
• هل التبعيات جاهزة (شبكة/قاعدة بيانات)؟
• هل المنفذ مشغول من عملية أخرى؟

الخلاصة

يُعد systemd وjournalctl من أهم الأدوات التي يحتاجها أي مدير خوادم Linux لتشخيص الخدمات المتوقفة بعد إعادة تشغيل السيرفر. فبدلًا من إعادة تشغيل الخدمات بصورة متكررة دون معرفة السبب، تساعدك قراءة السجلات على تحديد المشكلة بدقة، سواء كانت خطأ في الإعدادات، أو تعارضًا في المنافذ، أو نقصًا في الصلاحيات، أو فشلًا في التطبيق الخلفي.

باختصار، معظم الخدمات التي تفشل بعد إعادة التشغيل سببها عدم تفعيلها للإقلاع أو تبعية غير جاهزة. افحص الحالة، اقرأ السجل بـ journalctl، فعّل الخدمة، واضبط التبعيات — عندها لن تفاجئك الخدمات التي تفشل مجددًا.

وتوفّر مرام هوست خوادم VPS وDedicated بصلاحيات Root كاملة تمكّنك من ضبط الخدمات وسجلاتها بحرية، مع دعم فني عربي عند الحاجة.

واجعل الفحص الدوري عادة، راجع: الدليل الكامل لفحص صحة السيرفر (Server Health Check): أهم أوامر Linux لتشخيص الأعطال ومراقبة الأداء في 2026.

اعتماد منهجية واضحة تبدأ بفحص حالة الخدمة، ثم قراءة سجلاتها، ثم مراجعة المنافذ وملفات الإعداد، يوفر الكثير من الوقت ويقلل من فترة توقف المواقع والتطبيقات، ويجعل إدارة خوادم Linux أكثر احترافية واستقرارًا.