چیزی مدام یک واحد OpenVPN را راه‌اندازی می‌کند: منبع را پیدا کنید
غیرفعال کردن یک واحد با برداشتن فعال‌سازی آن یکی نیست. پیش از حذف یک نمایه، نمونه، نگاشت قالب و وابستگی‌های معکوس را بخوانید.
یک نمونه OpenVPN هنگام بوت با نامی بالا می‌آید که آن را نمی‌شناسید، و متوقف کردنش تا راه‌اندازی مجدد بعدی کار می‌کند. این الگو یعنی فرایند را برداشته‌اید اما فعال‌سازی را نه. این‌ها دو شیء متفاوت‌اند و فقط یکی از آن‌ها در صفحه وضعیت دیده می‌شود. یافتن فعال‌سازی چهار فرمان فقط-خواندنی و یک تصمیم می‌خواهد.
نخست واحد دقیق را نام ببرید
از نام واحد در journal شروع کنید، نه از نام پرونده نمایه. ممکن است نمونه openvpn@، openvpn-client@، openvpn-server@ یا چیزی مخصوص توزیع نام داشته باشد، و حدس زدن نام شما را به قالب نادرست می‌فرستد. خروجی وضعیت واحد را نام می‌برد که واقعاً اجرا شده، و همین تنها نامی است که اینجا اهمیت دارد. آن را دقیق کپی کنید، با هر پسوندی که دارد.
فرمان‌های زیر آن واحد را بدون تغییر دادن چیزی توصیف می‌کنند. systemctl show مسیر قطعه، مسیر منبع، وضعیت پرونده واحد، هر drop-in و آنچه آن را فعال کرده گزارش می‌کند. list-dependencies --reverse نشان می‌دهد کدام واحدهای بارگذاری‌شده به آن اشاره می‌کنند. هر دو فقط-خواندنی هستند، پس پیش از ساختن نظریه اجرایشان کنید.
نام مشاهده‌شده را همه‌جا جایگزین کنید. نام نمونه کپی‌شده رایج‌ترین راه بررسی سرویس نادرست است و پاسخ‌های مطمئنی درباره واحدی می‌دهد که هرگز اجرا نشده.
قالب را بخوانید تا نام پرونده را بدانید
واحد نمونه گسترش یک قالب است و قالب تعیین می‌کند کدام پرونده پیکربندی را می‌خواند. خط فرمانی که به یک جای‌نگهدار مخصوص نمونه ختم می‌شود به نام نمونه به‌همراه پسوند تبدیل می‌شود. اگر پسوند .conf باشد و نمونه old نام داشته باشد، پرونده old.conf است. اگر نمونه را old.conf بنامید، همان قالب old.conf.conf می‌خواهد.
این جزئیات یک دسته از تکرارها را توضیح می‌دهد. کسی نمونه دومی با نام نادرست اضافه می‌کند، اولی به کار خود ادامه می‌دهد و میزبان با دو تونل و یک گزارش گیج‌کننده می‌ماند.
قالب مؤثر را بخوانید، نه پرونده‌ای را که به یاد دارید ویرایش کرده‌اید. یک drop-in می‌تواند خط فرمان را جایگزین کند، و آنچه هنگام بوت اجرا می‌شود همان جایگزین است.
ردیابی کنید که چگونه به تراکنش بوت وارد می‌شود
سه مسیر رایج است: پیوند wants از یک هدف، نیازمندی از واحد دیگر، یا واحدی که یک مولد بسته ساخته است. فهرست وابستگی‌های معکوس دو مورد اول را به‌عنوان ورودی‌های بارگذاری‌شده گراف پوشش می‌دهد. تایمر، قلاب یا درخواست بیرونی را پوشش نمی‌دهد، از این رو فهرست یک شاهد است نه حسابرسی کامل.
خروجی تولیدشده زیر /run/systemd/generator یک محصول است، نه منبع. ویرایش آن تنها تا تولید بعدی می‌ماند، از این رو اصلاحی که آنجا اعمال شود موفق به نظر می‌رسد و سپس برمی‌گردد.
ورودی مستند بسته را بررسی کنید پیش از آنکه فرض کنید مولد از کجا می‌خواند. پیمایش مستندنشده یک پوشه دلیل معمول ظاهر شدن واحدی بدون پیوند فعال‌سازی است.
فعال‌سازی را بردارید، نه فقط فرایند را
اگر نمونه مستقیماً فعال شده و واقعاً منسوخ است، systemctl disable --now آن را متوقف می‌کند و پیوند بوت را در یک گام برمی‌دارد. نخست بررسی کنید که این تونل تنها مسیر مدیریتی شما به میزبان نباشد. فرمان یک نمونه چرخه عمر است، نه پیشنهادی برای متوقف کردن هر VPN روی دستگاه. بررسی را پیش از فرمان انجام دهید، نه پس از آن.
دو نیمه جداپذیرند و اغلب اشتباه گرفته می‌شوند. غیرفعال کردن سرویس در حال اجرا را متوقف نمی‌کند، و متوقف کردن فعال‌سازی را برنمی‌دارد، پس یک فرمان ناقص مشکلی را توضیح می‌دهد که هنگام بوت بازمی‌گردد.
واحد غیرفعال‌شده هنوز می‌تواند توسط واحد دیگر یا درخواستی صریح راه‌اندازی شود. وقتی مولد مالک فعال‌سازی است، ورودی مولد را اصلاح کنید نه اینکه خروجی‌اش را غیرفعال کنید. پوشاندن مسیرهای بیشتری را می‌بندد اما می‌تواند وابستگی‌ها را بشکند، پس جای فهم را نمی‌گیرد.
با راه‌اندازی مجدد تأیید کنید، نه با صفحه وضعیت
اگر تعریف‌های واحد یا ورودی‌های مولد تغییر کرده‌اند systemd را دوباره بارگذاری کنید، سپس وضعیت حاصل را بررسی کنید. بارگذاری مجدد دیمن نمایه جدیدی به تونل در حال اجرا هل نمی‌دهد، پس دو بررسی جدا از هم‌اند. یک راه‌اندازی مجدد زمان‌بندی کنید و تأیید کنید که نمونه غایب می‌ماند در حالی که تونل موردنظر هنوز کار می‌کند.
نمایه قدیمی را تا وقتی مالکیتش روشن شود نگه دارید، سپس آن را از طریق فرایند موردنظر بازنشسته کنید. موفقیت یک واحد غایب و مسیر دسترسی کارآمد است، نه واحدی ناموفق که از یک صفحه غایب باشد.