وحدة -.mount مقنَّعة: عميل OpenVPN لن يبدأ

تفشل خدمتك قبل أن يعمل OpenVPN إطلاقًا، والخطأ يتحدث عن وحدة تحميل لم تُعدّها قط. هذه هي العلامة: systemd يرفض المعاملة بأكملها لأن وحدة تحميل الجذر مقنَّعة، ولم يُقرأ ملف تعريف VPN بعد. السبب المعتاد هو ملف متبقٍ في دليل وحدات وقت التشغيل، وليس fstab تالفًا ولا شهادة مفقودة. تتبّع الملف أولًا، لأنه أبسط تفسير يمكن استبعاده.

الخطأ يذكر تحميل الجذر، لا ملف التعريف الخاص بك

يولّد systemd وحدة تحميل الجذر بنفسه من معلومات التحميل في النواة، ويسمي الوحدة -.mount لأن الشرطة تمثل مسار الجذر. هذه الوحدة توجد عادة في الذاكرة فقط وليس خلفها ملف. عندما يقول الخطأ إنها مقنَّعة، فقد وضع أحدهم ملف وحدة حيث سيحمّله systemd ووجّه ذلك الملف إلى /dev/null. التقنيع حالة حقيقية وليس خطأ مطبعيًا في الرسالة.

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

تحقق من دليل وقت التشغيل قبل أن تنقّح OpenVPN

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

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

الآلة العادية لا تحتوي على هذا الملف، وقائمة المقنَّعة لا تضم تحميل الجذر. إذا طبع الأمر الأول رابطًا رمزيًا إلى /dev/null، فقد حُسم التشخيص. قد يحتوي الدليل نفسه على تقنيع tmp.mount أنشأته الأدوات نفسها، وذلك ينتج الفئة نفسها من الفشل باسم آخر. انظر إلى الدليل كله وليس إلى الاسم في الخطأ فقط.

ls -la /run/systemd/system/*.mount

إذا كان الدليل نظيفًا والوحدة ما زالت مقنَّعة، فالتقنيع في مكان آخر من مسار البحث، وسيُظهر systemctl cat -.mount أي ملف يُحمَّل.

احذف الملف، وأعد التحميل، ثم ابدأ من جديد

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

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

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

journalctl -u [email protected] -b --no-pager

بما أن /run نظام ملفات مؤقت، فإن إعادة التشغيل تمسح الملف أيضًا. وهذا يجعل إعادة التشغيل اختبارًا مفيدًا: إذا عملت الخدمة بعد إعادة التشغيل وفشلت مجددًا بعد النشر التالي، فالملف مخبوز داخل الصورة.

امنع عودته من الصورة

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

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

العرض الذي يجب تذكّره هو عدم التطابق بين الخطأ والشيء الذي كنت تُعِدّه. عندما يشكو systemd من تحميل بينما تبدأ عميل VPN، اقرأ اسم الوحدة في الرسالة قبل اسم الخدمة.