إذا بدا أن خادم SUSE Linux يتوقف عن العمل أثناء إعادة التشغيل عند ظهور رسالة إيقاف تشغيل systemd، فإن الافتراض الأولي الأكثر فائدة ليس أن أمر إعادة التشغيل نفسه معطل. في معظم الحالات، ينتظر systemd انتهاء وحدة أو عملية ربط أو عملية أو خطاف إيقاف تشغيل. لذلك، فإن الحل الأمثل هو تحديد المهمة التي لا تزال قيد التشغيل، وفحص سبب عدم توقفها، وإصلاح ذلك الجزء بدلاً من تقصير مهلة إيقاف التشغيل بشكل عام.
يستخدم هذا الدليل مثالًا افتراضيًا : خادمٌ يُشغّل lab-sles01نظام SUSE Linux Enterprise Server ويتوقف مؤقتًا أثناء إعادة التشغيل مع ظهور رسالة مشابهة لما يلي A stop job is running for backup.service. هذا المثال هو مجرد توضيح لطريقة التشخيص، وليس تقريرًا عن اختبار حقيقي أو ادعاءً بوجود خلل في خدمة معينة في إصدار محدد من SUSE backup.service.
| خطوة | ما يجب القيام به | ما تحاول تعلمه |
|---|---|---|
| 1 | سجّل رسالة إيقاف التشغيل بدقة. | ما هي الوحدة أو المرحلة التي تعيق التقدم؟ |
| 2 | راجع سجل الأحذية السابق | سواءً انتهت مهلة الإيقاف، أو فشل فصل النظام، أو وصل الإغلاق إلى مرحلة لاحقة |
| 3 | افحص وحدة الحجب والوظائف المباشرة | سواء كانت الخدمة أو التركيب أو المثبط أو الاعتماد هي المسؤولة |
| 4 | أصلح السبب الجذري وأعد الاختبار | سواء systemctl rebootاكتملت الأمور بشكل طبيعي الآن دون تأخير |
راقب وحدة التحكم المحلية، أو وحدة تحكم الجهاز الظاهري، أو وحدة تحكم BMC/IPMI، أو وحدة تحكم المشرف أثناء إعادة التشغيل المخطط لها. يُعدّ سطرٌ يُسمّي وحدةً ما أكثر فائدةً بكثير من وصفٍ عام مثل "تجمّد systemd". على سبيل المثال lab-sles01، لنفترض أن وحدة التحكم تُظهر أن systemd backup.serviceلا يزال في حالة توقف بينما تم إيقاف تشغيل وحدات أخرى بالفعل.
مثال توضيحي: وحدة التحكم الخاصة بالإيقاف تحدد backup.serviceالوحدة التي لا يزال نظام systemd ينتظرها.
إذا أشارت وحدة التحكم إلى .mountوحدة، أو نظام ملفات شبكي، أو جهاز، أو خدمة أخرى، فاتبع هذا الاسم بدلاً من تطبيق مهلة خدمة عامة. الوحدة الظاهرة أسفل وحدة التحكم هي مجرد مؤشر، وليست بالضرورة السبب الجذري: فقد تكون هي نفسها تنتظر عملية فرعية، أو وحدة تخزين، أو إدخال/إخراج شبكي، أو أي تبعية أخرى.
تشير إرشادات SUSE الحالية لنظام systemd إلى أن إعادة التشغيل المطولة أو انقطاع التيار الكهربائي قد يكون سببه خدمة لا تتوقف عن العمل، وتوصي بفحص مهام systemd. راجع SUSE Linux Enterprise Server 16.0: مقدمة إلى أساسيات systemd .
بعد إعادة تشغيل الجهاز، افحص عملية الإيقاف التي حدثت للتو. توثق SUSE إزاحات الإقلاع في سجل النظام: boot 0هو الإقلاع الحالي، -1و boot هو الإقلاع السابق، وهكذا. ابدأ بـ:
sudo journalctl --list-boots
sudo journalctl -b -1
بالنسبة لسجلات كبيرة، يمكن أن يؤدي الترتيب العكسي إلى إظهار الرسائل الأخيرة بسرعة أكبر:
sudo journalctl -b -1 -r
مثال توضيحي: يُظهر سجل التمهيد السابق خدمة النسخ الاحتياطي الافتراضية التي تتلقى إشارة SIGTERM ثم تنتهي مهلتها لاحقًا.
ابحث عن عبارات مثل Stopping, stop job, timed out, Failed with result, Unmounting, Dependency failed, أو رسائل من الخدمة المشتبه بها نفسها. يمكنك تضييق نطاق البحث بمجرد معرفة اسم الوحدة.
sudo journalctl -b -1 -u backup.service
تُوثّق SUSE journalctl -b -1تحليل عمليات الإقلاع السابقة في وثائق سجل SLES 15 SP7 . إذا journalctl --list-bootsلم يتضمن السجل بيانات الإقلاع السابقة، فلا تستنتج استنتاجات بناءً على سجل مفقود؛ تحقق من كيفية تكوين وحدة تخزين journald واستخدم وحدة التحكم أو التسجيل عن بُعد لإعادة إنتاج المشكلة.
إذا تمكنت من إعادة إنتاج المشكلة خلال فترة الصيانة، فاحتفظ بوحدة تحكم إدارية ثانية متاحة. قبل انقطاع الاتصال، قم بتشغيل الأمر التالي:
sudo systemctl list-jobs
sudo systemctl status backup.service
مثال توضيحي: backup.serviceلديه مهمة إيقاف قيد التشغيل بينما ينتظر هدف إعادة التشغيل خلفها.
توضح إرشادات تصحيح أخطاء systemd الأصلية أن المهام التي تظهر على أنها runningيجب أن تنتهي قبل أن تتمكن المهام التابعة لها التي تظهر على أنها waitingمن المتابعة. كما توصي SUSE بذلك systemctl list-jobsعندما يستغرق إيقاف التشغيل أو إعادة التشغيل وقتًا طويلاً. وهذا يجعل هذا الأمر مفيدًا بشكل خاص عندما لا يكون الخادم متوقفًا تمامًا ويكون المعرّف PID 1 لا يزال يستجيب.
افحص تعريف الوحدة وسلوك إيقاف تشغيلها:
sudo systemctl cat backup.service
sudo systemctl status backup.service
sudo journalctl -u backup.service -b
تحقق مما إذا كانت الخدمة تقوم بأي ExecStop=إجراء، وما إذا كانت عمليتها تعالج إشارة SIGTERM، وما إذا كانت تنتظر موارد التخزين أو الشبكة. قد تحتاج قاعدة البيانات أو وكيل النسخ الاحتياطي أو خدمة البرمجيات الوسيطة إلى وقتٍ كافٍ لتفريغ البيانات، لذا فإن إيقافها مبكرًا ليس حلاً تلقائيًا.
ابحث عن عمليات إلغاء التحميل الفاشلة وحدد مصدر التحميل:
findmnt
systemctl list-units --type=mount
sudo journalctl -b -1 | grep -Ei 'unmount|umount|mount|nfs|cifs'
بالنسبة لبروتوكولي NFS أو CIFS، تحقق من إمكانية الوصول إلى الخادم، والجلسات القديمة، وما إذا كانت خيارات الربط تتوافق مع متطلبات إيقاف تشغيل الخادم. إذا تم إنشاء الوحدة المحظورة من خلال /etc/fstab، فقم بإصلاح تكوين الربط بدلاً من تطبيق مهلة زمنية خاصة بالخدمة على وحدة غير ذات صلة.
قبل بدء عملية الإغلاق، يمكنك سرد مثبطات نظام systemd النشطة:
systemd-inhibit --list
يمكن لأقفال التثبيط منع أو تأخير طلبات إيقاف التشغيل أثناء قيام تطبيق ما بعمل لا ينبغي مقاطعته. وتكون هذه الأقفال أكثر أهمية عندما يتأخر طلب إعادة التشغيل نفسه قبل أن يدخل النظام في تسلسل إيقاف التشغيل النهائي. راجع دليل systemd-inhibit الأصلي .
يتطلب التوقف في المراحل المتأخرة تحقيقًا مختلفًا. يقوم systemd بتشغيل الملفات التنفيذية /usr/lib/systemd/system-shutdown/قبل إعادة التشغيل النهائية أو إيقاف التشغيل مباشرةً، وينتظر حتى تنتهي. إذا أظهرت سجلات النظام ووحدة التحكم أن الخدمات العادية متوقفة بالفعل، وحدث التوقف في مرحلة الإغلاق النهائية، فراجع ذلك المجلد وأي خطافات مثبتة من قِبل المورّد. توضح وثائق خدمة إغلاق systemd الأصلية هذا السلوك.
لنعد إلى المثال الافتراضي lab-sles01. لنفترض أن السجلات تُظهر أن backup.serviceالنظام يتجاهل الإنهاء الطبيعي بعد اكتمال عملية النسخ الاحتياطي. الخيار الأول هو إصلاح الخدمة أو إيقافها. إذا كان من المعروف أن إنهاء الخدمة آمن بعد فترة زمنية محددة، فيمكن تجاوز إعدادات systemd لكل وحدة للحد من مدة انتظار systemd.
قم بإنشاء تجاوز بدلاً من تعديل وحدة البائع ضمن /usr/lib/systemd/system:
sudo systemctl edit backup.service
على سبيل المثال:
[Service]
TimeoutStopSec=30s
ثم أعد تحميل إعدادات وحدة systemd:
sudo systemctl daemon-reload
مثال توضيحي: يتم تطبيق مهلة لكل خدمة فقط بعد تحديد الخدمة الافتراضية على أنها العائق.
لا تقم بنسخ قيمة الثلاثين ثانية بشكل أعمى. يعتمد وقت الانتظار المناسب على ما يجب أن تُنهيه الخدمة الفعلية بأمان. قد يؤدي تقليله لقاعدة بيانات أو خادم تخزين أو خدمة مُجمّعة أو عملية نسخ احتياطي إلى تعطيل عملية التنظيف المشروعة. يُعد وقت الانتظار بمثابة إجراء وقائي، وليس بديلاً عن إصلاح ExecStop=إجراء معطّل أو تطبيق لا يُنهي عمله بشكل صحيح.
عندما تكون راضيًا عن التغيير، اختبر إعادة التشغيل العادية:
sudo systemctl reboot
بعد عودة الجهاز، راجع عملية التشغيل السابقة مرة أخرى وتأكد من أن الوحدة توقفت بشكل سليم بدلاً من مجرد اختفائها من وحدة التحكم.
إعادة التشغيل القسري هي خيار للاستعادة، وليست استراتيجية لحل المشكلات. تشير وثائق systemd الأصلية إلى أن إعادة التشغيل القسري تتجاوز إيقاف الخدمة العادي، لكنها --forceمع systemctl rebootذلك تُنهي العمليات وتحاول فصل أو إعادة تحميل أنظمة الملفات للقراءة فقط. يُعدّ تكرار --forceهذه العملية أكثر خطورة، لأنه قد يُعيد التشغيل دون إنهاء العمليات أو فصل أنظمة الملفات، مما يُعرّض البيانات لخطر الفقدان.
إذا كان الخادم عالقًا بالفعل ولا توجد طريقة أكثر أمانًا لاستعادة الخدمة، فقد يكون إعادة التشغيل القسري مبررًا بموجب إجراءات التشغيل الخاصة بك:
sudo systemctl reboot --force
تجنّب التعامل مع systemctl reboot --force --forceإعادة تشغيل الجهاز افتراضيًا أو إعادة ضبطه فعليًا كحلٍّ عادي. فقد تؤدي هذه الإجراءات إلى إزالة الأدلة التي تحتاجها، كما قد تُعرّض عمليات الكتابة الجارية للخطر. توضح وثائق systemctl الأصلية بوضوح الفرق بين سلوكيات الإجبار الفردي والإجبار المزدوج.
استخدم وحدة تحكم الصيانة وقم بتشغيل وضع الإنقاذ. توفر SUSE وثائق لإضافة أوامر systemd.unit=rescue.targetإلى سطر أوامر النواة من محرر GRUB. يوفر وضع الإنقاذ جلسة مستخدم بصلاحيات الجذر مع أنظمة الملفات المحلية والخدمات الأساسية مع تعطيل الشبكة، مما يساعدك على تعطيل أو إصلاح الخدمة أو إعدادات التحميل المُسببة للمشكلة.
راجع دليل إدارة SLES 15 SP7 للاطلاع على الإجراء الرسمي لوضع الإنقاذ. في الأنظمة التي تظهر فيها المشكلة فقط بعد تغيير حزمة أو نواة أو برنامج تشغيل أو وحدة تخزين معينة، راجع أيضًا سجل صيانة SUSE ذي الصلة قبل إجراء تغييرات دائمة على مهلة الانتظار.
| ما تراه | المنطقة المحتملة للتفتيش | أفضل إجراء تالٍ |
|---|---|---|
A stop job is running for xyz.service | مسار إيقاف الخدمة | تحقق من systemctl statusملف الوحدة وسجل الخدمة |
| رسائل متكررة حول إلغاء التحميل أو نظام الملفات البعيد | التثبيت، NFS، CIFS، التخزين | تحقق من findmntوحدات التثبيت، /etc/fstabوتأكد من إمكانية الوصول إلى الخادم |
| تم رفض طلب إعادة التشغيل أو تأخيره قبل الإغلاق | مثبط أو وظيفة أخرى في نظام systemd | اركض systemd-inhibit --listوsystemctl list-jobs |
| تم إيقاف الخدمات، لكن الإغلاق النهائي لم يكتمل أبدًا | خطاف إيقاف التشغيل المتأخر، النواة، برنامج التشغيل، التخزين | راجع سجل عمليات الإقلاع السابقة و/usr/lib/systemd/system-shutdown/ |
| يجعل الحذاء العادي عملية الإصلاح مستحيلة | خلل مستمر في التكوين أو الوحدة | حذاء رياضي معsystemd.unit=rescue.target |
في حالة تعطل خادم SUSE Linux عند إيقاف تشغيل systemd، يكمن الحل الدائم في تحديد المهمة التي ينتظرها systemd وتصحيح تلك المهمة أو تبعيتها. سجّل رسالة الإيقاف، وافحصها journalctl -b -1، واستخدم أدوات مثل `systemd` systemctl list-jobsو` systemctl statussystemd` لعزل المشكلة، ثم غيّر مهلة الخدمة أو إعدادات التثبيت. احتفظ بطرق إعادة التشغيل القسري لحالات الاسترداد فقط، وليس للعمليات الروتينية.
قم بإصلاح مشكلة تمزق الشاشة في معالجات رسومات Intel في نظام Pardus Linux عن طريق التحقق من X11 مقابل Wayland، وإعدادات المُركِّب، ومعدل التحديث، وبرنامج تشغيل Xorg النشط، وTearFree فقط عند الاقتضاء.
قم بتكوين firewalld على SLES 15: تحقق من المناطق، واسمح بالخدمات أو المنافذ، واحفظ القواعد الدائمة، وأعد التحميل بأمان، وتحقق من الوصول.
قم بتمكين التصحيح المباشر للنواة على SLES 15 SP7، وقم بتطبيق الإصلاحات المدعومة دون إعادة التشغيل، وتحقق من التصحيحات النشطة، وافهم متى لا تزال إعادة تشغيل النواة مطلوبة.
قم بتمكين وضع FIPS على SLES 15 باستخدام أداة الإعداد المدعومة من SUSE، وأعد التشغيل بأمان، وتحقق من حالة سياسة النواة والتشفير، وتحقق من حدود الشهادة.
قم بتثبيت متصفح جوجل كروم على نظام التشغيل Gooroom OS بأمان باستخدام حزم .deb الرسمية، وAPT، وفحوصات السياسات، وإرشادات التحديث، وإصلاحات الأجهزة المُدارة.
إعادة توجيه سجلات نظام SLES بشكل آمن إلى خادم syslog بعيد باستخدام rsyslog وشهادات TLS والتحقق من اسم النظير وقوائم الانتظار والتحقق من الصحة والاختبار.
قم بربط نظام SLES 15 بـ Active Directory باستخدام SSSD عبر YaST. قم بإعداد DNS والوقت، وتكوين تسجيلات دخول المجال، والتحقق من Kerberos، ومقارنة SSSD وWinbind وrealmd.
Fix RTL8821CE Wi-Fi on Pardus Linux by checking the built-in rtw88 driver, Realtek firmware, rfkill, NetworkManager, and safe fallback options.
تشخيص وإصلاح حالات فشل تحليل DNS في Debian 12 باستخدام systemd-resolved، بما في ذلك resolv.conf و NetworkManager و networkd و cache و verification.
قم بتثبيت Pardus 25.2 بجانب Windows 11 عن طريق النسخ الاحتياطي، وتقليص حجم وحدة تخزين Windows، والتمهيد من USB UEFI، وحماية أقسام EFI والاسترداد الحالية.
