اگر Ubuntu یا Debian هنگام Boot مدت زیادی روی systemd-networkd-wait-online.service میماند، معمولاً مشکل این نیست که خود systemd خراب شده باشد. این سرویس منتظر میماند Interfaceهای شبکهای که توسط systemd-networkd مدیریت میشوند به وضعیت قابلقبول برسند. اگر یک Interface کابل نداشته باشد، DHCP پاسخ ندهد، IPv6 منتظر بماند یا Interfaceای که عملاً استفاده نمیکنید Required محسوب شود، Boot ممکن است تا پایان Timeout متوقف بماند.
پاسخ سریع: ابتدا با networkctl مشخص کنید کدام Interface در وضعیت configuring، no-carrier یا off مانده است. اگر آن Interface برای Boot ضروری نیست، در Netplan آن را با optional: true مشخص کنید. اگر فقط یک Interface خاص برای اتصال سرور مهم است، میتوانید Wait Online را روی همان Interface محدود کنید.
systemd-networkd-wait-online چه کاری انجام میدهد؟
systemd-networkd-wait-online.service یک سرویس oneshot است که منتظر میماند شبکه به وضعیت Online برسد.
بهصورت پیشفرض:
🔹 Interfaceهای Managed توسط systemd-networkd را بررسی میکند.
🔹 منتظر میماند Linkها Configured یا Failed شوند.
🔹 حداقل یک Link باید Online باشد.
🔹 Timeout پیشفرض آن ۱۲۰ ثانیه است.
در systemd، وضعیت Online پیشفرض معمولاً از Operational State لینک تعیین میشود و برای بیشتر Interfaceها حداقل حالت degraded در نظر گرفته میشود.
نشانه رایج مشکل
هنگام Boot ممکن است چیزی شبیه این ببینید:
A start job is running for Wait for Network to be Configured
یا بعد از ورود به سیستم:
systemd-networkd-wait-online.service: start operation timed out
مرحله ۱: ببینید واقعاً Boot کجا کند شده است
بعد از بالا آمدن سرور اجرا کنید:
systemd-analyze blame
اگر خروجی شبیه این باشد:
2min 1.234s systemd-networkd-wait-online.service
تقریباً مشخص است Boot منتظر شبکه مانده است.
مرحله ۲: وضعیت Wait Online را بررسی کنید
systemctl status systemd-networkd-wait-online.service --no-pager -l
Log سرویس:
journalctl -u systemd-networkd-wait-online.service -b --no-pager
مرحله ۳: Interface مشکلدار را پیدا کنید
اول این دستور را اجرا کنید:
networkctl
یا:
networkctl list
ممکن است خروجی چیزی شبیه این باشد:
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 eth1 ether no-carrier configuring
در این مثال، eth0 مشکلی ندارد اما eth1 بدون Carrier مانده و احتمالاً Wait Online منتظر آن است.
مرحله ۴: وضعیت یک Interface خاص را ببینید
networkctl status eth1
همچنین:
ip link show eth1
ip address show eth1
رایجترین علت: Interface اختیاری ولی Required برای Boot
روی VPS یا سرور ممکن است Interface دومی داشته باشید که همیشه متصل نیست؛ مثلاً:
🔹 کارت شبکه دوم
🔹 Interface خصوصی
🔹 VLAN
🔹 Bridge
🔹 Adapter قدیمی یا بدون Carrier
اگر این Interface برای Boot ضروری نیست، بهتر است systemd منتظر آن نماند.
راهحل پیشنهادی در Netplan: optional: true
ابتدا فایلهای Netplan را ببینید:
ls -l /etc/netplan/
نمونه تنظیم:
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: true
eth1:
dhcp4: true
optional: true
در Netplan، Deviceای که optional: true دارد برای Boot الزامی محسوب نمیشود و networkd برای Online شدن آن منتظر نمیماند. این قابلیت مخصوص Backend نوع networkd است. :chatgpt-content-reference{index=”1″}
روی VPS Remote مستقیم netplan apply نزنید
قبل از تغییر تنظیم شبکه، Syntax را بررسی کنید:
sudo netplan generate
سپس روی سرور Remote بهتر است از:
sudo netplan try
استفاده کنید تا در صورت قطع اتصال یا تأیید نشدن تنظیم، امکان Rollback وجود داشته باشد.
راهحل مستقیم در systemd-networkd: RequiredForOnline=no
اگر Netplan استفاده نمیکنید و فایلهای .network را مستقیماً مدیریت میکنید، میتوانید Interface غیرضروری را از تصمیم Online بودن خارج کنید.
مثال:
[Match]
Name=eth1
[Network]
DHCP=yes
RequiredForOnline=no
طبق مستندات systemd، وقتی RequiredForOnline=no باشد، آن Link هنگام تعیین Online بودن سیستم نادیده گرفته میشود؛ حتی اگر کابل متصل نباشد یا DHCP Address نگیرد. :chatgpt-content-reference{index=”2″}
اگر فقط eth0 برای سرور مهم است
systemd یک Template Service دارد که میتواند فقط برای Interface مشخص منتظر بماند:
systemd-networkd-wait-online@eth0.service
طبق مستندات، این Unit فقط روی Interface مشخصشده با گزینه -i منتظر میماند. :chatgpt-content-reference{index=”3″}
اما قبل از تغییر Unitهای Boot مطمئن شوید سرویسهای دیگری واقعاً به Interface دوم نیاز ندارند.
⚠️ صرفاً Mask کردن Wait Online بدون بررسی وابستگیها همیشه راهحل مناسبی نیست. سرویسهایی مثل Remote Mount، Backup، Database Client یا Applicationهایی که واقعاً به شبکه هنگام Boot نیاز دارند ممکن است بعداً Fail شوند.
آیا میتوان systemd-networkd-wait-online را Disable کرد؟
از نظر فنی بله، اما قبل از آن باید بررسی کنید چه Unitهایی به network-online.target وابسته هستند.
اول Dependencyها را بررسی کنید:
systemctl list-dependencies network-online.target
اگر مطمئن شدید هیچ سرویس حیاتی به Online شدن قطعی شبکه هنگام Boot نیاز ندارد، میتوانید تصمیم بگیرید Wait Online لازم است یا نه.
Boot سرور بهخاطر شبکه طولانی شده است؟
در VPSهایی با چند Interface، Private Network، Docker Bridge، Tunnel یا تنظیمات Netplan سفارشی، بهتر است Interfaceهای Required و Optional دقیق مشخص شوند تا Boot بدون انتظار غیرضروری انجام شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
راهحل برای Interface بدون Carrier
اگر Interface فیزیکی یا مجازی در Boot کابل یا Carrier ندارد:
networkctl status eth1
ip link show eth1
اگر این Interface برای سرویسدهی اصلی سرور استفاده نمیشود، بهترین راه معمولاً Optional کردن آن است، نه کاهش کورکورانه Timeout کل سرویس.
گیرکردن روی DHCP
اگر Interface روی DHCP تنظیم شده ولی DHCP Server پاسخ نمیدهد، Link ممکن است مدت زیادی در وضعیت configuring باقی بماند.
وضعیت DHCP را با Logهای networkd بررسی کنید:
journalctl -u systemd-networkd -b --no-pager
اگر Interface باید Static باشد، تنظیم DHCP را اصلاح کنید. اگر DHCP لازم است، مشکل DHCP Server، VLAN یا Connectivity را برطرف کنید.
IPv6 نیز میتواند باعث انتظار شود؟
بله، بسته به تنظیم Interface و نسخه systemd، Wait Online میتواند منتظر Family موردنیاز برای Online شدن Link بماند.
systemd از گزینههایی مثل:
--ipv4
--ipv6
--any
پشتیبانی میکند. گزینه –any اجازه میدهد اگر چند Interface دارید، Online شدن یکی از آنها برای موفقیت کافی باشد؛ این گزینه مخصوصاً زمانی مفید است که بعضی Interfaceها ممکن است در Boot Carrier نداشته باشند. :chatgpt-content-reference{index=”4″}
کمکردن Timeout؛ راهحل یا مسکن؟
Wait Online گزینه –timeout= دارد و مقدار پیشفرض آن ۱۲۰ ثانیه است. :chatgpt-content-reference{index=”5″}
میتوان Timeout را کمتر کرد، اما اگر Interface اشتباهی Required است، این کار فقط مدت انتظار را کاهش میدهد و علت اصلی را حل نمیکند.
اول Interface مشکلدار را پیدا و تنظیم Required/Optional را اصلاح کنید؛ بعد فقط در صورت نیاز واقعی Timeout را تغییر دهید.
اگر NetworkManager استفاده میکنید چه؟
اگر Renderer شما NetworkManager است، سرویس مرتبط معمولاً:
NetworkManager-wait-online.service
است، نه systemd-networkd-wait-online.
NetworkManager نیز Wait Online مخصوص خودش را دارد و میتواند رسیدن سیستم به network-online.target را تا تکمیل Startup شبکه به تأخیر بیندازد. :chatgpt-content-reference{index=”6″}
Renderer فعال Netplan را بررسی کنید:
sudo netplan get
بعد از اصلاح Netplan چه چیزهایی را تست کنیم؟
اول:
sudo netplan generate
سپس روی VPS Remote:
sudo netplan try
بعد:
networkctl
ip address
ip route
تست نهایی بعد از Reboot
اگر سرویسهای Production آماده Restart هستند:
sudo reboot
بعد از بالا آمدن سرور:
systemd-analyze blame
networkctl
systemctl status systemd-networkd-wait-online.service --no-pager
اگر زمان Wait Online به چند میلیثانیه یا چند ثانیه منطقی کاهش پیدا کرده و Interface اصلی Online است، مشکل برطرف شده است.
جدول تشخیص سریع
| نشانه | راه بررسی |
|---|---|
| Boot حدود ۲ دقیقه گیر میکند | systemd-analyze blame |
| Interface دوم no-carrier است | optional: true یا RequiredForOnline=no |
| DHCP پاسخ نمیدهد | Log systemd-networkd و DHCP |
| فقط eth0 مهم است | Wait فقط برای Interface لازم |
| NetworkManager فعال است | بررسی NetworkManager-wait-online |
پرسشهای متداول
چرا systemd-networkd-wait-online حدود ۱۲۰ ثانیه طول میکشد؟
چون Timeout پیشفرض Wait Online برابر ۱۲۰ ثانیه است و یکی از Interfaceهای Required احتمالاً به وضعیت Online نمیرسد.
آیا optional: true شبکه Interface را غیرفعال میکند؟
خیر. فقط باعث میشود آن Device برای ادامه Boot ضروری محسوب نشود. Interface همچنان توسط Backend شبکه تنظیم میشود.
آیا میتوان wait-online را Mask کرد؟
از نظر فنی ممکن است، اما باید ابتدا بررسی کنید سرویسهایی مثل Remote Mount یا Applicationهای وابسته به network-online.target به آن نیاز دارند یا نه.
فرق systemd-networkd-wait-online با NetworkManager-wait-online چیست؟
اولی برای Backend نوع systemd-networkd است و دومی برای NetworkManager. اینکه کدام سرویس مرتبط است به Renderer شبکه سیستم بستگی دارد.
چرا یک Interface بدون کابل Boot را کند میکند؟
اگر Interface RequiredForOnline باشد، Wait Online منتظر میماند به وضعیت لازم برسد. برای Interface غیرضروری باید آن را Optional تعریف کنید.
آیا کاهش Timeout بهترین راهحل است؟
معمولاً خیر. ابتدا مشخص کنید چرا Interface Online نمیشود. کاهش Timeout فقط مدت انتظار را کم میکند.
منابع رسمی
🔹 systemd-networkd-wait-online manual
🔹 systemd.network و RequiredForOnline
🔹 Netplan؛ optional و optional-addresses
جمعبندی
اگر systemd-networkd-wait-online باعث کند شدن Boot شده است، قبل از Disable کردن سرویس مشخص کنید کدام Interface منتظر Online شدن است. در سرورهایی که Interface فرعی یا بدون Carrier دارند، optional: true در Netplan یا RequiredForOnline=no در systemd-networkd معمولاً راهحل تمیزتری است. کاهش Timeout یا Mask کردن کامل Wait Online را فقط زمانی انجام دهید که Dependencyهای network-online.target را بررسی کرده باشید.
Boot VPS همچنان روی Wait Online گیر میکند؟
اگر چند Interface، Netplan سفارشی، Private Network یا Route خاص دارید، میتوانید برای بررسی networkd، Interfaceهای Required و Logهای Boot درخواست فنی ثبت کنید.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467






دیدگاهها (۰)