فایل PID هست، تونلی در کار نیست: آیا OpenVPN هرگز اجرا شد؟
یک فایل PID باقی‌مانده هیچ چیزی درباره فعال بودن تونل نمی‌گوید. پیش از حذف آن، سرویس، زمان شروع فرایند و قرارداد راه‌انداز را بررسی کنید.
وقتی راه‌انداز از اجرای OpenVPN خودداری می‌کند چون فایل PID از قبل وجود دارد، خوانش طبیعی این است که تونلی جایی در حال اجراست. این خوانش به‌قدر کافی اغلب نادرست است که پیش از حذف هر چیزی ارزش بررسی داشته باشد. فایل در پوشه اجرا حسابداری است، و حسابداری از خرابی‌ها، راه‌اندازی‌های مجدد و خاموشی‌های نیمه‌کاره‌ای که فرایندی بر جای نگذاشتند جان سالم به در می‌برد. دو پرسش موضوع را روشن می‌کند: آیا فرایند زنده‌ای وجود دارد، و آیا آن فرایند به این نمونه تعلق دارد.
با سرویس شروع کنید، نه با فایل
امتناع معمولاً از یک راه‌انداز می‌آید نه از خود OpenVPN. مسیری را می‌خواند، چیزی آنجا پیدا می‌کند و پیش از تجزیه پیکربندی متوقف میشود. پس پرسش نخست درباره قرارداد راه‌انداز است، نه درباره تونل.
واحد یا اسکریپتی را که پیام را چاپ کرده بخوانید و به سه چیز توجه کنید: مسیری که بررسی می‌کند، نوع سرویسی که اعلام می‌کند، و اینکه آیا اصلاً مسئول نوشتن فایل است. یک واحد مدرن می‌تواند از نظارت ساده یا اعلانی استفاده کند و هرگز به فایل PID دست نزند، در حالی که یک اسکریپت init قدیمی می‌تواند خودش یکی بسازد. کپی کردن یک بررسی از یک مدل به مدل دیگر دقیقاً همین نوع امتناع را پدید می‌آورد. پیش از تفسیر هر چیزی بفهمید کدام مدل به کار می‌رود.
تنها آن‌گاه پرسش این میشود که آیا نمونه‌ای واقعاً در حال اجراست.
بررسی کنید آیا آن شناسه به نمونه شما تعلق دارد
عددی در یک فایل ثابت می‌کند که عددی نوشته شده است. ثابت نمی‌کند که فرایندی با آن شناسه اکنون وجود دارد، و قطعاً ثابت نمی‌کند که آن فرایند مال شماست، چون شناسه‌ها پس از راه‌اندازی مجدد دوباره استفاده می‌شوند.
زمان شروع فرایند را با مُهر زمانی فایل، فایل اجرایی را با فرمان واحد، و عضویت در سرویس را با نام واحد مقایسه کنید. ناسازگاری در هر یک از این سه یعنی شما به حسابداری نگاه می‌کنید نه به تونل.
روی میزبانی که کانتینر یا چند فضای نام اجرا می‌کند، یک شناسه ممکن است در یک نما معنادار و در نمای دیگر غایب باشد. ندیدن یک فرایند هم شاهد نبودن آن نیست، اگر حساب شما نتواند آن را بررسی کند. پیش از نتیجه‌گیری از همان بافتاری که راه‌انداز استفاده می‌کند بررسی کنید.
systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"راه‌انداز چه وعده‌ای درباره فایل داده بود
PIDFile= به مدیر سرویس می‌گوید شناسه فرایند اصلی را از کجا بخواند. مدیر آن فایل را نمی‌نویسد، اما فایل بازمانده را پس از خاموشی حذف می‌کند، و دقیقاً به همین دلیل یک خروج نیمه‌کاره می‌تواند فایلی بر جای بگذارد.
این تقسیم مسئولیت دو نشانه‌ای را توضیح می‌دهد که مردم آن‌ها را باگ گزارش می‌کنند. فایلی که هرگز ظاهر نمی‌شود یعنی دیمن یا اسکریپتش نتوانسته آن را بنویسد، نه اینکه نظارت بد پیکربندی شده است. فایلی که از یک توقف جان سالم به در می‌برد یعنی مسیر خاموشی هرگز کامل نشده است.
همچنین توضیح می‌دهد چرا راهنمایی‌های امروزی پیشنهاد می‌کنند وقتی نظارت می‌تواند فرایند اصلی را مستقیم دنبال کند از این قرارداد پرهیز شود. آن راهنمایی اجازه تغییر نوع یک واحد بسته‌بندی‌شده نیست، چون رفتار دیمن در پیش‌زمینه، در شاخه‌شدن یا در اعلان باید با آنچه واحد اعلام می‌کند بخواند. نوع را بدون تغییر دیمن عوض کنید و واحدی می‌گیرید که هنگام اجرای تونل شکست گزارش می‌کند، یا برعکس. این جفت را هماهنگ کنید یا هر دو را رها کنید. مرجع سرویس systemd این تقسیم مالکیت را توصیف می‌کند.
خاموشی پاک در برابر خروج نیمه‌کاره
توقف پاک از دیمن می‌خواهد خارج شود، منتظرش می‌ماند و به مدیر اجازه می‌دهد حسابداری خودش را مرتب کند. خروج نیمه‌کاره، فرایند کشته‌شده یا راه‌اندازی مجدد در میانه خاموشی بخش‌هایی از این توالی را جا می‌اندازد، و فایل همان چیزی است که می‌ماند. پیدا کردن یکی پس از خرابی به شما می‌گوید خاموشی تمام نشده، نه اینکه چیزی گوش می‌دهد.
مُهر زمانی فایل را با آخرین بوت و با آخرین توقف واحد مقایسه کنید.
سپس شواهد زنده را مستقیم بررسی کنید. سوکتی که به درگاه VPN بسته شده و یک رابط تونل با نشانی، شاهد آن است که چیزی در حال اجراست، به شکلی که یک فایل متنی در پوشه اجرا هرگز نیست. اگر هر دو غایب باشند، هیچ چیز اجرا نمی‌شود، هر چه فایل ادعا کند.
حذف فایل را به‌عنوان عادت کنار بگذارید
حذف آن یک گام بازیابی مشروع است، پس از آنکه ثابت کردید هیچ نمونه‌ای مالک آن نیست و راه‌انداز این رفتار را مستند می‌کند.
به‌عنوان عادتی دائمی پیش از شروع، همان بررسی‌ای را که دور می‌زنید بی‌اثر می‌کند. اگر فایل‌های کهنه پس از هر توقف پاک بازگردند، نویسنده و چرخه عمر خاموشی بر سر اینکه مسیر از آن کیست توافق ندارند، و همان ناسازگاری باگ ارزش اصلاح است.
راهی مستقل به میزبان نگه دارید، یک نمونه را از طریق مدیر عادی‌اش اجرا کنید، و نخستین نتیجه را بخوانید. نفر بعدی واحدی می‌گیرد که یا کار می‌کند یا خودش را توضیح می‌دهد.