ملف PID موجود ولا نفق: هل كان OpenVPN يعمل يومًا؟

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

ابدأ بالخدمة لا بالملف

الرفض يأتي عادة من المشغّل لا من OpenVPN نفسه. يقرأ مسارًا ويجد شيئًا هناك ويتوقف قبل تحليل الإعدادات. السؤال الأول إذن يتعلق بعقد المشغّل لا بالنفق.

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

عندها فقط يصبح السؤال هل نسخة ما تعمل فعلًا.

تحقق مما إذا كان ذلك المعرّف يخص نسختك

رقم في ملف يثبت أن رقمًا قد كُتب. لا يثبت أن عملية بهذا المعرّف موجودة الآن، وبالتأكيد لا يثبت أن العملية لك، لأن المعرّفات يُعاد استخدامها بعد إعادة التشغيل.

قارن وقت بدء العملية بطابع الوقت في الملف، والملف التنفيذي بأمر الوحدة، وعضوية الخدمة باسم الوحدة. أي تعارض في الثلاثة يعني أنك تنظر إلى محاسبة لا إلى نفق.

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

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

ما وعد المشغّل بفعله بالملف

PIDFile= يخبر مدير الخدمة بمكان قراءة معرّف العملية الرئيسية. المدير لا يكتب ذلك الملف، لكنه يزيل ملفًا باقيًا بعد الإغلاق، ولهذا بالضبط قد يترك خروج متقطع ملفًا خلفه.

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

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

الإغلاق النظيف مقابل الخروج المتقطع

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

قارن طابع وقت الملف بآخر إقلاع وبآخر إيقاف للوحدة.

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

توقف عن حذف الملف كعادة

حذفه خطوة استرداد مشروعة بمجرد أن تثبت أن لا نسخة تملكه وأن المشغّل يوثّق هذا السلوك.

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

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