تشخيص خادم SUSE الذي يتوقف عند شاشة إيقاف تشغيل systemd

إذا توقف خادم SUSE Linux Enterprise Server عن العمل أثناء إيقاف تشغيل systemd، فحدد الوحدة التي بها مهمة إيقاف قيد التشغيل أو افحص الرسائل الأخيرة من عملية التشغيل السابقة، ثم أصلح تلك الوحدة أو تبعياتها. الوحدة هي مورد مُدار بواسطة systemd مثل خدمة أو وحدة تخزين؛ ومهمة الإيقاف هي طلب systemd لإيقاف تشغيلها. لا تقم بتقليل مهلة النظام العامة أو فرض إيقاف التشغيل كحل أولي، لأن الخدمة أو نظام الملفات قد لا يزال يُغلق الملفات أو يكتب البيانات.

يتبع هذا الدليل وثائق SLES 15 SP7 التي تم التحقق منها في أكتوبر 2026. وتعتمد سياسة الإيقاف الدقيقة على مورد الخدمة والتخزين، لذا استخدم إرشاداتهم لأي تغييرات خاصة بالوحدة.

1. راقب عملية الإغلاق بأمان

الخطوة الأولى: سجل الرسالة بدقة وانتظر الحصول على دليل مفيد

إذا عرضت وحدة التحكم رسالة "عملية إيقاف قيد التشغيل لـ..." مع عد تنازلي، فدوّن اسم الخدمة أو نقطة التحميل وما إذا كان المؤقت قد تغير. هذا يعني أن systemd ينتظر عملية إيقاف تلك الوحدة، وليس بالضرورة أن نظام التشغيل قد تعطل؛ فقد تحتاج قواعد البيانات ووحدات التخزين البعيدة إلى وقت للإغلاق بشكل صحيح.

راقب النظام عبر وحدة تحكم عن بُعد أو منفذ تسلسلي، أو أي طرفية متاحة أخرى. تجنب استخدام أوامر إعادة الضبط أو الطاقة أثناء عمليات الكتابة. إذا توقف النظام عن الاستجابة، سجّل آخر سطر مرئي، ثم تابع بعد إعادة تشغيله.

2. ابحث عن الوحدة التي تنتظر

الخطوة الثانية: فحص مهام systemd للتأكد من أن الجهاز لا يزال يقبل الأوامر

إذا كان SSH أو طرفية ثانية لا يزال يعمل، فاسأل systemd عن المهام التي تعمل أو تنتظر، ثم تحقق من الوحدة المسماة على الشاشة:

sudo systemctl list-jobs
sudo systemctl status SERVICE.service

استبدل SERVICEباسم الوحدة الفعلي. تُضيّق مهمة الإيقاف الجارية نطاق البحث، لكنها لا تُفسّر سبب عدم انتهاء العملية. اقرأ حالتها وسجلاتها قبل تغيير الإعدادات. إذا لم يعد systemd يستجيب، فلا تُلغِ المهام بشكل عشوائي؛ بل افحص السجل السابق بعد عودة المضيف.

3. استخدم عملية إعادة التشغيل السابقة لتحديد السبب

الخطوة 3: اقرأ نهاية سجل الحذاء السابق

السجل هو سجل مفهرس لرسائل النواة والخدمات والنظام في نظام systemd. بعد بدء التشغيل الناجح التالي، اعرض قائمة عمليات بدء التشغيل المسجلة وافحص نهاية عملية بدء التشغيل السابقة.

sudo journalctl --list-boots
sudo journalctl -b -1 -e

ابحث عن آخر رسالة "إيقاف"، أو رسالة انتهاء المهلة، أو عدد المحاولات، أو اسم الجهاز أو نقطة التثبيت. السطر الأخير مجرد دليل: قد يؤدي إيقاف التشغيل إلى ترك وحدة أخرى تنتظر. قارن الطوابع الزمنية والرسائل المجاورة.

الخطوة الرابعة: تصفية السجلات للخدمة المشتبه بها

عندما تُشير الشاشة أو السجل إلى خدمة ما، استعلم فقط عن إدخالات التمهيد السابقة لتلك الوحدة. راجع أيضًا التكوين المُحمّل الخاص بها:

sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service

تحقق من وجود أي خطأ مخصص ExecStop، أو برنامج نصي ينتظر إلى أجل غير مسمى، أو عملية فرعية عالقة، أو خطأ في التطبيق عند إيقاف تشغيله. بالنسبة لوحدات البائع، قارن الحزمة والتكوين مع الإرشادات المدعومة قبل التعديل.

الخطوة 5: تحقق من أماكن التثبيت والتخزين فقط عندما تشير الأدلة إلى ذلك

إذا كان سجل النظام يشير إلى وحدة تخزين أو جهاز أو نظام ملفات بعيد، فافحص جدول وحدات التخزين والإدخال المطابق في /etc/fstab:

sudo findmnt --verify --verbose

تحقق من إمكانية الوصول إلى أي اتصال بعيد، سواء كان NFS أو CIFS أو iSCSI أو غيره، أثناء إيقاف التشغيل. لا تقم بإزالة أي إدخال ربط قديم إلا بعد التأكد من عدم استخدامه. لا تقم بإلغاء ربط نظام ملفات قيد التشغيل قسرًا بناءً على إعادة تشغيل بطيئة فقط.

4. عالج السبب دون إخفائه

الخطوة 6: إصلاح الخدمة أو تعديل سياسة الإيقاف الموثقة الخاصة بها فقط

بالنسبة للخدمة التي لا تتوقف، قم أولاً بإصلاح برنامج إيقاف التشغيل، أو إعدادات التطبيق، أو مشكلة الحزمة. sudo systemctl edit SERVICE.serviceيتم تخزين ملف التثبيت لكل وحدة في مجلد معين /etc/systemd/system/دون الحاجة إلى تعديل ملف المورّد. TimeoutSecتستخدم وثائق SUSE لبدء الخدمة أو إيقافها قيمة معتمدة من المورّد لهذا النوع من العمل.

بعد إجراء تعديل موثق، أعد تحميل تعريفات وحدات systemd باستخدام الأمر المناسب sudo systemctl daemon-reload، ثم افحص النتيجة باستخدام الأمر المناسب sudo systemctl cat SERVICE.service. قد يسمح مهلة زمنية أطول بإتمام عملية إيقاف التشغيل بشكل صحيح، ولكنها قد تُطيل أيضًا عملية إعادة التشغيل الفاشلة. أما المهلة الأقصر فقد تُنهي خدمةً قبل أن تُفرغ حالتها. لا تُغير الإعدادات الافتراضية العامة لإخفاء عيب في وحدة واحدة.

الخطوة 7: الاحتفاظ بالسجلات للحادث التالي

يخزن نظام SLES بيانات السجل في مجلد /run/log/journal/افتراضيًا، ويتم مسح هذا المجلد المؤقت عند إعادة التشغيل. إذا journalctl -b -1لم يكن يحتوي على أي إدخالات من عمليات التشغيل السابقة، فقم بتمكين تخزين السجل الدائم لأغراض التشخيص المستقبلية.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush

تستخدم السجلات الدائمة مساحةً ضمن نظام الملفات /var؛ وتشير SUSE إلى أن السجل قد يستخدم ما يصل إلى 10% من هذا النظام افتراضيًا. تحقق من المساحة الحرة وفترة الاحتفاظ، خاصةً على /varوحدات التخزين الصغيرة.

5. تحقق من إعادة التشغيل المخطط لها التالية

الخطوة 8: تأكد من اكتمال عملية الإيقاف وعودة الخادم إلى الخدمة

بمجرد تصحيح السبب المشتبه به، قم بجدولة إعادة تشغيل مُتحكم بها مع إتاحة الوصول إلى وحدة التحكم. بعد عودة الجهاز، افحص الرسائل النهائية لعملية التشغيل السابقة وتحقق من الحالة الحالية للخدمة.

sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service

تُحل المشكلة عند إيقاف تشغيل الخادم دون انتظار على نفس الوحدة، ثم إعادة تشغيله بشكل طبيعي، ونجاح الخدمة أو عملية الربط. إذا توقفت السجلات فجأة أو أظهرت أخطاءً في النواة أو وحدة التحكم أو الأجهزة، فاحتفظ بها وتحقق من الأمر مع SUSE أو مُصنِّع الأجهزة بدلاً من ضبط مهلة الاستجابة.

للحصول على تفاصيل الأوامر، راجع دليل SLES 15 SP7 systemd ودليل SUSE للسجلات الدائمة وفلاتر journalctl . تُحدد هذه الخطوات العوامل المُحتملة المُسببة للمشكلة؛ ويعتمد الحل الصحيح، سواءً كان متعلقًا بالخدمة أو نظام الملفات أو الأجهزة، على الوحدة المُشار إليها في سجلات الجهاز نفسه.