systemctl می‌گوید systemd همان PID 1 نیست: پس چه؟

اگر systemctl start openvpn-client@office را اجرا کنید و پیامی بگیرید که سیستم با systemd بوت نشده است، این پیام مثل یک خرابی سرویس به نظر می‌رسد. اما اصلاً خرابی سرویس نیست: systemctl که فراخوانده‌اید نمی‌تواند مدیر در حال اجرایی برای گفت‌وگو پیدا کند، بنابراین هیچ چیز درباره OpenVPN بررسی نشده است. sudo مدیری ایجاد نمی‌کند، و نصب یک فایل unit هم آن را ایجاد نمی‌کند. فرمان و ماشین از دو دنیای متفاوت می‌آیند، و خطا تنها جایی است که این موضوع خودش را نشان داد.

با این پرسش شروع کنید که کدام فرایند در جایی که فرمان اجرا می‌شود مالک PID 1 است، چون همین پاسخ تعیین می‌کند که آیا اصلاً unit وجود دارد یا نه.

خطا محیط را نام می‌برد، نه OpenVPN را

systemctl یک کلاینت است، نه مدیر. از طریق یک سوکت به مدیر سیستم وصل می‌شود، و وقتی در سر دیگر مدیری نباشد، همان پیامی را چاپ می‌کند که مردم در انجمن‌ها می‌چسبانند. ps -p 1 -o pid=,comm= نشان می‌دهد واقعاً چه چیزی به‌عنوان PID 1 اجرا می‌شود، و پاسخ غالباً یک shell، یک پوشش init یا ورودی خود کانتینر است. در چنین حالتی ممکن است فایل unit کاملاً معتبر باشد و با این حال هرگز خوانده نشود. تکرار فرمان با کاربر root فقط اعتبارنامه‌های کلاینت را تغییر می‌دهد.

پیش از خط اول، کل پیام را بخوانید. خطایی از خود مدیر، مانند unit گمشده یا شرط ناموفق، یعنی به مدیری رسیده‌اید؛ اما این خطا یعنی نرسیده‌اید.

WSL: فعال کردن systemd یک تغییر پیکربندی است

WSL در نسخه‌های بعدی از systemd پشتیبانی کرد، اما این قابلیت برای هر توزیع جداگانه فعال می‌شود و فقط جایی کار می‌کند که نسخه نصب‌شده WSL از آن پشتیبانی کند. wsl --version در سمت Windows نشان می‌دهد چه دارید، و فایل /etc/wsl.conf توزیع شامل [boot] بخشی با systemd=true است. آن فایل را بدون حذف بخش‌های موجود ویرایش کنید، سپس نمونه WSL را دوباره راه‌اندازی کنید تا تغییر اعمال شود. wsl --shutdown هر توزیع در حال اجرا را متوقف می‌کند، پس اول کارتان را ذخیره کنید.

پس از باز کردن دوباره، پیش از دست زدن به unit OpenVPN مدیر را تأیید کنید: ps -p 1 -o comm= باید systemd را گزارش دهد. فعال کردن systemd هیچ پروفایلی، هیچ اعتبارنامه‌ای و هیچ نام نمونه‌ای نمی‌دهد، بنابراین خطای بعدی درباره یکی از این‌ها خواهد بود، نه PID 1.

کانتینرها ورودی خود را اجرا می‌کنند، نه unitها را

یک کانتینر معمولی همان چیزی را شروع می‌کند که ورودی یا فرمانش مشخص می‌کند، و مهم نیست چه بسته‌هایی نصب کنید، ماشینی نیست که با systemd بوت شده باشد. افزودن systemctl به ایمیج، کلاینتی به شما می‌دهد که چیزی برای اتصال ندارد. برای Community OpenVPN الگوی پشتیبانی‌شده معمولاً یک فرایند در پیش‌زمینه است، openvpn --config /path/to/client.conf، که ورودی آن را شروع می‌کند و از بیرون نظارت می‌شود. همان مالک راه‌اندازی، سیگنال‌ها و خاموشی را مدیریت می‌کند و باید تنها چیزی باشد که تونل را اداره می‌کند.

هرگز یک نسخه تعاملی را کنار ورودی‌ای که آن تونل را اداره می‌کند اجرا نکنید، چون دو فرایند بر سر دستگاه و مسیرها با هم می‌جنگند. یک فرایند init حداقلی درون کانتینر فرزندان را جمع می‌کند و سیگنال‌ها را منتقل می‌کند؛ اما ایمیج را به میزبان دارای unit تبدیل نمی‌کند.

اگر یک استقرار واقعاً به systemd درون کانتینر نیاز دارد، به ایمیجی نیاز دارد که آگاهانه برای این کار طراحی شده باشد، نه اختیارات اضافه‌ای که افزوده شود تا systemctl شکایت را متوقف کند.

وقتی مدیر وجود دارد، خطای بعدی را بخوانید

وقتی مدیری واقعی سرویس را راه می‌اندازد، خطاهای مفید شروع می‌شوند. خرابی مجوز دستگاه، خطای تجزیه پیکربندی، اعتبارنامه گمشده و همتایی که در دسترس نیست، چهار مشکل متفاوت‌اند که پیام PID 1 هرگز آن‌ها را آزمایش نکرد. آن‌ها را به ترتیبی بخوانید که unit تولید کرده است، با journalctl -u openvpn-client@office -n 50 روی میزبان systemd، یا با اجرای کلاینت در پیش‌زمینه جایی که مدیری وجود ندارد. اجرای پیش‌زمینه همچنین سریع‌ترین راه برای تأیید این است که خود پروفایل کار می‌کند.

دو محیط را در یادداشت‌هایتان جدا نگه دارید: میزبانی که تونل را اجرا می‌کند، و جایی که فرمان‌ها را تایپ می‌کنید.