رفع خطای no command specified در Container میکروتیک؛ آموزش کامل بررسی cmd و EntryPoint در RouterOS
خطای no command specified یکی از خطاهایی است که ممکن است هنگام اجرای Container در MikroTik RouterOS با آن مواجه شوید. این خطا معمولاً زمانی ظاهر میشود که RouterOS نتواند دستور اصلی اجرای Container یا EntryPoint مورد نیاز Image را پیدا یا استفاده کند.
اگر Container شما قبلاً بدون مشکل اجرا میشده اما پس از ارتقای RouterOS، تغییر Image، تغییر Configuration یا انتقال Container به Router دیگری با خطای no command specified, set cmd or entrypoint متوقف شده است، لازم نیست بلافاصله Container را حذف و از ابتدا نصب کنید. در بسیاری از موارد میتوان با بررسی دقیق cmd، entrypoint، Image، Architecture و Log علت مشکل را پیدا کرد.
⚠️ نکته مهم
خطای no command specified لزوماً به معنی خراب بودن Image نیست. ممکن است Image کاملاً سالم باشد اما RouterOS نتواند Command یا EntryPoint مورد نیاز آن را از Configuration فعلی دریافت کند. بنابراین قبل از حذف Image، ابتدا Configuration و Log را بررسی کنید.
خطای no command specified در MikroTik دقیقاً یعنی چه؟
Container برای اجرا به یک فرآیند اصلی نیاز دارد. این فرآیند میتواند از طریق اطلاعات موجود در Image مشخص شده باشد یا هنگام ایجاد Container توسط کاربر تعیین شود.
در صورتی که RouterOS هنگام Start کردن Container نتواند Command یا EntryPoint معتبر پیدا کند، ممکن است خطایی شبیه پیام زیر نمایش داده شود:
start failed: no command specified, set cmd or entrypoint
معنای ساده این پیام این است که RouterOS برای شروع فرآیند اصلی Container، دستور اجرایی مناسبی در اختیار ندارد.
Command یا CMD چیست؟
CMD دستوری است که Container هنگام اجرا میتواند از آن برای شروع فرآیند اصلی خود استفاده کند. در Imageهای مختلف، CMD ممکن است برای اجرای یک سرویس، اسکریپت یا فایل اجرایی خاص تعریف شده باشد.
بنابراین اگر CMD در Image وجود نداشته باشد، RouterOS نتواند آن را تشخیص دهد یا Configuration شما آن را به شکل نادرست Override کند، Container ممکن است Start نشود.
EntryPoint چیست؟
EntryPoint مشخص میکند فرآیند اصلی Container از چه فایل یا برنامهای شروع شود. برای مثال یک Image ممکن است اسکریپتی مانند start.sh را به عنوان نقطه شروع خود داشته باشد.
اگر EntryPoint مورد انتظار Image در RouterOS Override شده باشد یا مسیر آن اشتباه باشد، Container ممکن است هنگام Start با خطای مربوط به Command یا EntryPoint متوقف شود.
چرا این خطا در Container میکروتیک ایجاد میشود؟
برای خطای no command specified چند سناریوی مختلف وجود دارد. مهم است که قبل از تغییر Configuration بدانید مشکل شما در کدام دسته قرار میگیرد.
🔹 Image فاقد Command یا EntryPoint مناسب است.
🔹 مقدار cmd در Configuration اشتباه وارد شده است.
🔹 مقدار entrypoint به مسیر اشتباه اشاره میکند.
🔹 بعد از ارتقای RouterOS، رفتار Command تغییر کرده است.
🔹 Image با Architecture دستگاه سازگار نیست.
🔹 فایل EntryPoint داخل Image وجود ندارد یا قابل اجرا نیست.
🔹 Configuration قدیمی Container با نسخه جدید RouterOS سازگار نیست.
🔹 Container با App یا Configuration دیگری ایجاد شده و Command آن Override شده است.
مرحله اول؛ نسخه RouterOS را بررسی کنید
اگر این خطا بعد از Upgrade ظاهر شده، اولین کار مشخص کردن نسخه دقیق RouterOS است. عبارت «RouterOS 7» برای عیبیابی کافی نیست.
/system resource print
نسخه دقیق RouterOS را یادداشت کنید. اگر مشکل دقیقاً پس از Upgrade ایجاد شده است، این اطلاعات برای مقایسه با نسخه قبلی بسیار مهم خواهد بود.
مرحله دوم؛ وضعیت دقیق Container را مشاهده کنید
قبل از تغییر هر چیزی، Configuration فعلی Container را مشاهده کنید:
/container print detail
در خروجی به موارد زیر دقت کنید:
🔹 نام Container
🔹 Image
🔹 cmd
🔹 entrypoint
🔹 root-dir
🔹 interface
🔹 logging
🔹 status
اگر در Configuration مقدار cmd یا entrypoint خالی یا غیرمنتظره است، احتمالاً مسیر اصلی عیبیابی را پیدا کردهاید.
مرحله سوم؛ بررسی مقدار cmd
برای دیدن اطلاعات Container میتوانید از دستور زیر استفاده کنید:
/container print detail where name="نام-container"
به جای نام-container نام واقعی Container را قرار دهید.
اگر Container شما قبل از Upgrade کار میکرد و بعد از Upgrade خطای no command specified میدهد، مقدار CMD فعلی را با Configuration قبلی مقایسه کنید.
تغییر رفتار cmd در RouterOS 7.23
یکی از نکات مهم در بررسی این خطا، مخصوصاً در RouterOS 7.23، تغییر رفتار گزارششده برای Property مربوط به cmd است.
در برخی گزارشهای کاربران، Configurationای که در نسخههای 7.22.x بدون مشکل اجرا میشده، بعد از انتقال به 7.23 رفتار متفاوتی نشان داده است. این مسئله بهخصوص زمانی اهمیت پیدا میکند که Command شامل کاما یا چند Argument باشد.
در چنین شرایطی ممکن است چیزی که کاربر یک Command واحد تصور میکند، در RouterOS جدید به شکل متفاوتی تفسیر شود.
⚠️ اگر Command شما کاما دارد
Command را بدون بررسی تغییر ندهید. ابتدا Configuration را Export کنید و مشخص کنید کاما بخشی از Argument است یا باید به عنوان جداکننده Argumentها استفاده شود.
مرحله چهارم؛ بررسی EntryPoint
اگر Image دارای EntryPoint مشخص است، باید مطمئن شوید RouterOS به مسیر صحیح اشاره میکند.
برای نمونه اگر Image دارای فایل start.sh در مسیر مناسب باشد، میتوان EntryPoint را مطابق ساختار واقعی Image تنظیم کرد:
/container set [find name="نام-container"] entrypoint="start.sh"
این دستور را کورکورانه اجرا نکنید. فایل EntryPoint باید واقعاً در Image وجود داشته باشد. اگر نام فایل یا مسیر متفاوت است، باید مقدار واقعی آن را استفاده کنید.
اگر بعد از تنظیم EntryPoint هنوز خطا دارید
اگر خطا از بین رفت اما Container بلافاصله Stop شد، احتمالاً مشکل اولیه رفع شده و اکنون باید خطای داخل برنامه را بررسی کنید.
در این حالت Logging را فعال کنید:
/container set [find name="نام-container"] logging=yes
سپس Container را اجرا کنید:
/container start [find name="نام-container"] /log print
مرحله پنجم؛ Image را مقصر ندانید، Architecture را بررسی کنید
یکی دیگر از دلایل رایج شکست Container، ناسازگاری Architecture است. Image باید با معماری CPU دستگاه شما سازگار باشد.
برای مثال Imageهای amd64 برای دستگاههای x86/CHR مناسب هستند، در حالی که Routerهای ARM یا ARM64 به Image سازگار با معماری خود نیاز دارند.
برای بررسی سختافزار:
/system resource print
اگر Container قبل از تغییر نسخه RouterOS روی همین سختافزار اجرا میشده، Architecture احتمالاً علت اصلی نیست؛ اما همچنان باید در عیبیابی بررسی شود.
برای اجرای آزمایشی Container به سرور مناسب نیاز دارید؟
اگر برای تست MikroTik CHR، Container، سرویسهای شبکه یا سناریوهای آزمایشگاهی به منابع اختصاصیتر نیاز دارید، یک VPS مناسب میتواند محیط جداگانهای برای آزمایش Configurationهای RouterOS در اختیار شما قرار دهد.
ایرانیکاسرور سرویسهای سرور مجازی و VPS میکروتیک را برای سناریوهای مختلف شبکه ارائه میکند.
📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
مرحله ششم؛ Storage و root-dir را بررسی کنید
Container برای اجرای صحیح به Root Directory و Storage معتبر نیاز دارد. اگر مسیر Container تغییر کرده، Disk جدا شده یا فضای ذخیرهسازی کافی وجود ندارد، اجرای Container ممکن است با مشکل مواجه شود.
ابتدا Storage را بررسی کنید:
/disk print
سپس مقدار root-dir را در خروجی Container بررسی کنید. اگر مسیر به Storageای اشاره میکند که دیگر در دسترس نیست، ابتدا Storage را اصلاح کنید.
مرحله هفتم؛ Package مربوط به Container را بررسی کنید
Packageها باید با نسخه RouterOS هماهنگ باشند. برای مشاهده Packageهای نصبشده:
/system package print
اگر Package مربوط به Container نصب نیست یا نسخه آن با RouterOS اصلی هماهنگ نیست، ابتدا این مسئله را اصلاح کنید.
مرحله هشتم؛ Container Mode را بررسی کنید
قابلیت Container به Device Mode وابسته است. وضعیت فعلی را بررسی کنید:
/system device-mode print
اگر Container Mode فعال نباشد، ابتدا باید وضعیت Device Mode را اصلاح کنید. بدون بررسی وضعیت فعلی، دستور تغییر Device Mode را اجرا نکنید؛ زیرا برخی تغییرات نیازمند Reboot یا تأیید فیزیکی هستند.
اگر Container با App ایجاد شده است
در RouterOSهای جدید ممکن است Container بهصورت مستقیم یا از طریق قابلیت App مدیریت شود. اگر Container شما توسط App ایجاد شده، بررسی فقط /container کافی نیست.
وضعیت App را نیز بررسی کنید:
/app print /app settings print
در چنین شرایطی ممکن است Configuration مربوط به App روی Command یا EntryPoint Container تأثیر گذاشته باشد.
آیا با تغییر EntryPoint مشکل همیشه حل میشود؟
خیر. تغییر EntryPoint فقط در صورتی منطقی است که بدانیم Image واقعاً چه EntryPointای دارد.
اگر شما بهصورت تصادفی مقدار start.sh، /bin/sh یا یک فایل دیگر را به عنوان EntryPoint قرار دهید، ممکن است خطای اولیه تغییر کند اما Container همچنان کار نکند.
⚠️ اصل مهم در عیبیابی
EntryPoint را از روی حدس تعیین نکنید. ابتدا Documentation مربوط به Image یا Dockerfile آن را بررسی کنید و ببینید برنامه با چه Command و EntryPointای طراحی شده است.
Dockerfile را برای پیدا کردن Command اصلی بررسی کنید
اگر Image متعلق به خودتان است یا Dockerfile آن را در اختیار دارید، بهترین روش این است که مقدار ENTRYPOINT و CMD را مستقیماً در Dockerfile بررسی کنید.
ENTRYPOINT ["/app/start.sh"] CMD ["--config", "/app/config.yml"]
در این مثال، برنامه با فایل /app/start.sh شروع میشود و دو Argument نیز دریافت میکند. اگر Configuration RouterOS با این ساختار مطابقت نداشته باشد، ممکن است Container اجرا نشود.
چرا Container قبل از Upgrade کار میکرد ولی حالا no command specified میدهد؟
اگر Image و Router شما تغییر نکردهاند و تنها نسخه RouterOS عوض شده است، احتمال تغییر رفتار یا Regression در نسخه جدید باید در نظر گرفته شود.
این سناریو بهخصوص در RouterOS 7.23 اهمیت پیدا میکند؛ زیرا در گزارشهای کاربران تغییراتی در رفتار Container و Commandها مشاهده شده است.
در چنین شرایطی این ترتیب را دنبال کنید:
🔹 نسخه فعلی RouterOS را ثبت کنید.
🔹 Configuration فعلی Container را Export کنید.
🔹 cmd و entrypoint را با نسخه قبلی مقایسه کنید.
🔹 Changelog نسخه RouterOS را بررسی کنید.
🔹 نسخههای بعدی RouterOS را نیز بررسی کنید.
🔹 فقط در صورت نیاز Downgrade را به عنوان تست در نظر بگیرید.
آیا Downgrade برای رفع no command specified مناسب است؟
Downgrade ممکن است به عنوان یک تست تشخیصی مشخص کند مشکل پس از تغییر نسخه RouterOS ایجاد شده است، اما نباید بدون Backup و بررسی سازگاری انجام شود.
اگر Container در نسخه قبلی کار میکرد و در نسخه جدید با خطای مشخصی متوقف میشود، مقایسه رفتار دو نسخه اطلاعات ارزشمندی میدهد. با این حال، بهتر است ابتدا Changelog نسخههای جدیدتر را بررسی کنید؛ زیرا ممکن است مشکل در نسخههای بعدی اصلاح شده باشد.
بررسی Log؛ مهمترین مرحله بعد از no command specified
اگر تغییر Configuration نتیجه نداد، Log را بررسی کنید. فعال کردن Logging:
/container set [find name="نام-container"] logging=yes
بعد از Start کردن Container:
/container start [find name="نام-container"] /log print
اگر خطای دیگری بعد از no command specified ظاهر شد، همان خطای جدید را مبنای مرحله بعد قرار دهید. ممکن است خطای اول فقط علامت Configuration نادرست بوده باشد و پس از اصلاح آن، مشکل واقعی داخل برنامه نمایان شود.
اگر Container اجرا شد اما سرویس داخل آن کار نکرد
اگر بعد از اصلاح Command یا EntryPoint، Container در حالت Running قرار گرفت اما سرویس قابل دسترسی نیست، دیگر مشکل اصلی no command specified نیست.
در این مرحله باید موارد زیر را بررسی کنید:
🔹 VETH
🔹 IP Address
🔹 Gateway
🔹 Route
🔹 DNS
🔹 NAT
🔹 Firewall
🔹 Port سرویس
برای بررسی Interfaceهای مجازی:
/interface veth print detail
چه زمانی Container را حذف کنیم؟
حذف Container باید یکی از آخرین مراحل باشد، نه اولین مرحله. اگر Volume یا Data مهم داخل Container دارید، حذف عجولانه میتواند باعث از دست رفتن اطلاعات شود.
قبل از حذف:
🔹 از Configuration Export بگیرید.
🔹 مسیر root-dir را ثبت کنید.
🔹 Volumeها را بررسی کنید.
🔹 Image و Tag دقیق را یادداشت کنید.
🔹 CMD و EntryPoint را ذخیره کنید.
🔹 اطلاعات Network را ثبت کنید.
خطای no command specified را نمیتوانید رفع کنید؟
اگر Container شما بعد از تغییر نسخه RouterOS اجرا نمیشود یا با خطای Command و EntryPoint مواجه شده است، قبل از حذف Image و از دست دادن Configuration، میتوانید تنظیمات و خطاهای خود را برای بررسی تخصصی ارسال کنید.
📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
مستندات رسمی برای بررسی Container در MikroTik
برای بررسی دقیق Syntax و رفتار Container، بهتر است در کنار این راهنما از مستندات رسمی MikroTik نیز استفاده کنید.
مستندات رسمی Container در MikroTik
انجمن رسمی MikroTik برای Container
جمعبندی؛ رفع خطای no command specified
خطای no command specified در Container میکروتیک معمولاً به این معناست که RouterOS نمیتواند دستور اصلی اجرای Container یا EntryPoint معتبر را پیدا یا اجرا کند.
برای رفع آن ابتدا نسخه RouterOS، Package، Architecture و وضعیت Device Mode را بررسی کنید. سپس با /container print detail مقدارهای cmd و entrypoint را مشاهده کنید.
اگر مشکل بعد از RouterOS 7.23 ایجاد شده است، تغییر رفتار گزارششده cmd و Regressionهای مرتبط با Container را نیز در نظر بگیرید. مخصوصاً Commandهایی که دارای کاما یا چند Argument هستند باید با دقت بررسی شوند.
در نهایت Logging را فعال کنید و پیام واقعی هنگام Start را ببینید. حذف و نصب مجدد Container اولین راهکار نیست؛ ابتدا Configuration و Data را حفظ کنید و سپس بر اساس خطای واقعی اقدام کنید.
سوالات متداول درباره خطای no command specified
خطای no command specified در Container میکروتیک چیست؟
این خطا نشان میدهد RouterOS هنگام Start کردن Container نتوانسته Command یا EntryPoint معتبر برای اجرای فرآیند اصلی Container پیدا کند.
آیا مشکل no command specified به معنی خراب بودن Docker Image است؟
خیر. Image ممکن است کاملاً سالم باشد و مشکل از Configuration، cmd، entrypoint یا نحوه تفسیر آن توسط RouterOS باشد.
چرا بعد از RouterOS 7.23 این خطا ظاهر شده است؟
در برخی سناریوها تغییرات بخش Container و رفتار cmd در RouterOS 7.23 باعث شده Configurationهایی که در نسخههای قبلی کار میکردند، نیازمند بررسی یا اصلاح شوند.
آیا با تغییر EntryPoint خطا حل میشود؟
اگر EntryPoint صحیح Image مشخص باشد و RouterOS نتواند آن را به شکل صحیح استفاده کند، تنظیم درست آن میتواند مشکل را برطرف کند؛ اما نباید EntryPoint را بدون شناخت Image حدس زد.
چطور cmd یک Container را بررسی کنیم؟
با اجرای /container print detail و بررسی Configuration مربوط به Container میتوان مقدار cmd و سایر Propertyهای آن را مشاهده کرد.
آیا باید Container را حذف و دوباره نصب کنیم؟
خیر. ابتدا از Configuration Export بگیرید و cmd، entrypoint، Image، Storage، Architecture و Log را بررسی کنید.
اگر بعد از رفع no command specified، Container فوراً Stop شد چه کنیم؟
در این حالت مشکل اولیه Command یا EntryPoint احتمالاً تغییر کرده است و باید Log برنامه، Exit Code، فایل اجرایی و Configuration داخل Container را بررسی کنید.
دیدگاهها
0 دیدگاه برای این مطلب ثبت شده است.