status=200/CHDIR: لم يشغّل systemd خادم OpenVPN إطلاقًا
فشل CHDIR يعني أن systemd لم يستطع الدخول إلى مجلد، وليس أن OpenVPN لم يستطع قراءة ملف تعريف. اقرأ الوحدة قبل أن تلمس إعدادات VPN.
تفشل الخدمة، وتذكر السجلات عملية إنشاء ومجلدًا، ويكون الانطباع الأول فحص إعدادات VPN. لم يُقرأ شيء من ذلك الملف بعد. فشل systemd أثناء تحضير العملية، قبل تشغيل الملف التنفيذي، لذلك لم يُستشَر أي محلل ولا أي شهادة ولا أي مضيف بعيد. قراءة رمز الحالة كبيان عن systemd بدلًا من OpenVPN هي ما يحوّل هذا إلى تحقيق قصير.
اقرأ رمز الحالة قبل التطبيق
يسمّي الرمز الرقمي بعد اسم الخدمة المرحلة التي فشلت. يُبلّغ عن فشل المجلد كحالة CHDIR، بينما الملف التنفيذي الذي تعذّر تشغيله رمز مختلف تمامًا. يبدو الاثنان متشابهين في سطر ملخص ولا يشتركان في شيء في أسبابهما.
يهمني ذلك التمييز لأن الإصلاحات في ملفات مختلفة. فشل CHDIR يتعلق بمسار وبكيفية رؤية الخدمة له. فشل exec يتعلق بالملف الثنائي أو مفسّره أو بتحميل غير ذي صلة. تغيير النقطة البعيدة لـ VPN أو قائمة التشفير أو مسار الشهادة لا يعالج أيا منهما.
أكّد أن الفشل عند البدء وليس بعد تشغيل ناجح. إذا كانت الخدمة تعمل أمس وتفشل الآن في المرحلة نفسها، فقد تغيّر شيء في المجلد أو أذونه أو الوحدة نفسها، وذلك التغيير هو الدليل الذي تبحث عنه.
اسأل الوحدة أين تريد أن تكون
اقرأ الوحدة الفعلية لا الملف الذي تظن أنه مثبّت، لأن ملفات drop-in يمكنها تجاوز مجلد العمل دون أن تعدّل الوحدة الرئيسية أبدًا. مخرجات show تجيب السؤال مباشرة:
systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30في قالب خادم upstream، مجلد العمل هو مجلد إعدادات الخادم، بينما اسم النسخة يختار الملف الشخصي داخله. لذلك تتوقع نسخة تُسمى branch ملفها الخاص في المجلد نفسه، ولا يفي ملف شخصي موضوع في مكان آخر بمتطلب مجلد العمل إطلاقًا.
قارن ما تطلبه الوحدة بما هو موجود. المسار الذي كان موجودًا، أو رابط رمزي يشير الآن إلى مكان آخر، أو اسم نسخة لم يعد يطابق مجلدًا، كلها تغييرات عادية تُنتج هذا الفشل تحديدًا.
افحص المسار كما تراه الخدمة
صدفتك والخدمة لا تشتركان في الرؤية نفسها لنظام الملفات. مجلد جذر أو صورة جذر مُهيّأة تغيّر معنى المسار المطلق داخل الوحدة، وقد يكون مسار موجود بوضوح على المضيف غائبًا في تلك المساحة الاسمية. اقرأ إعدادات الوحدة قبل الوثوق باختبار يدوي.
الأذونات تفاقم المشكلة. تعمل الخدمة كمستخدم محدد، وعلى هذا المستخدم أن يستطيع عبور كل مجلد أب للوصول إلى الهدف، لا مجرد قراءة الهدف نفسه. المجلد الذي يمكن لـ root قراءته ولا يمكن لمستخدم الخدمة عبوره يُنتج فشلًا يبدو كمسار مفقود.
namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPathsإعدادات التحصين أيضًا جزء من هذه الصورة. الوحدة التي تخفي مجلدات المنزل أو تجعل جزءًا من نظام الملفات للقراءة فقط تفعل بالضبط ما هُيّئت له، ويجب أن يوجد مجلد العمل في مكان لا يزال فيه الصندوق الرملي يعرضه.
أصلح المالك ثم توقّع خطأً آخر
صحّح التخطيط أو الوحدة عبر من يملك ذلك الإعداد. نقل ملف شخصي إلى المجلد المتوقع إصلاح مشروع عندما يكون التخطيط خاطئًا، لكنه لا يفسّر مجلدًا لا يمكن الدخول إليه، فلا تتعامل معه كالجواب العام.
قاوم الحل السريع بتوسيع الأذونات على شجرة الإعدادات أو إزالة الصندوق الرملي. كلاهما يُخفي العَرَض بينما يزيل الحمايات التي وُضعت هناك عن قصد، وسيكون الفشل التالي أصعب في التفسير.
أعد تشغيل النسخة واقرأ الحدث التالي بدلًا من افتراض النجاح. الخطأ التالي المرجح هو أن OpenVPN لا يستطيع فتح ملف إعداداته، وهذا تقدّم: دُخل مجلد العمل والمحلل يعمل الآن. تابع من هناك خريطة ملفات الوحدة الفعلية بدلًا من العودة إلى استكشاف أخطاء الشبكة.
يحدد مرجع تنفيذ systemd كيف يُفسَّر مجلد العمل إلى جانب مجلدات الجذر والعزل. النمط الجدير بالتذكّر بسيط: كل رمز حالة يسمّي مرحلة مختلفة، وأخطاء التطبيق نفسه وحدها هي التي تصف التطبيق.