اگر بعد از ارتقای MikroTik RouterOS به نسخه 7.23 یا یکی از نسخه‌های 7.23.x متوجه شده‌اید که Containerهای قبلی دیگر Start نمی‌شوند، با خطاهایی مانند no command specified, set cmd or entrypoint مواجه می‌شوید یا Container بلافاصله بعد از اجرا متوقف می‌شود، احتمال زیادی وجود دارد که مشکل از تغییرات و Regressionهای بخش Container باشد؛ نه الزاماً از Docker Image یا تنظیمات شبکه شما.

این مشکل در گزارش‌های کاربران RouterOS پس از ارتقا از نسخه‌های قدیمی‌تر مانند 7.19.x به 7.23.1 دیده شده و حتی در انجمن رسمی MikroTik نیز نمونه‌هایی از Containerهایی که قبل از ارتقا بدون مشکل کار می‌کردند اما بعد از ارتقا با خطای مربوط به cmd یا entrypoint متوقف شده‌اند، گزارش شده است.

مشکل Container بعد از RouterOS 7.23 دقیقاً چیست؟

در RouterOS 7.23 تغییرات قابل توجهی در بخش Container و App ایجاد شد. در کنار قابلیت‌های جدید، تعدادی Regression نیز توسط کاربران گزارش شد. یکی از موارد مهم، تغییر رفتار cmd در Container بود که در برخی سناریوها باعث می‌شد مقداری که در نسخه‌های قبل به شکل یک رشته استفاده می‌شد، در نسخه 7.23 رفتار متفاوتی داشته باشد.

برای مثال، اگر Container شما به یک دستور خاص، آرگومان‌های متعدد یا مقدارهایی شامل کاما وابسته باشد، ممکن است همان تنظیمی که در RouterOS 7.22.x بدون مشکل اجرا می‌شده، پس از ارتقا به 7.23 رفتار متفاوتی نشان دهد.

از طرف دیگر، یک گزارش مشخص درباره Containerهایی وجود دارد که پس از ارتقا به RouterOS 7.23.1 با خطای start failed: no command specified, set cmd or entrypoint مواجه شدند، در حالی که Container قبل از ارتقا بدون تغییر خاصی کار می‌کرد.

MikroTik در یکی از همین گزارش‌ها اعلام کرده بود که این رفتار در حال بررسی است و برای یک سناریوی مشخص، Override کردن EntryPoint به‌عنوان راهکار موقت پیشنهاد شد.

آیا RouterOS 7.23 Container را کلاً خراب کرده است؟

خیر. چنین نتیجه‌ای دقیق نیست. Container همچنان یکی از قابلیت‌های رسمی RouterOS 7 است و برای معماری‌های مشخصی مانند ARM، ARM64 و x86/CHR پشتیبانی می‌شود. همچنین Package مربوط به Container باید نصب باشد و قابلیت Container در Device Mode فعال شده باشد.

مشکل اصلی این است که برخی Containerهای موجود، مخصوصاً Containerهایی که به EntryPoint خاص، Command خاص یا ساختار خاصی از Image وابسته‌اند، ممکن است پس از ارتقا نیاز به بررسی یا اصلاح داشته باشند.

مرحله اول؛ نسخه RouterOS را دقیق بررسی کنید

اولین اشتباه رایج این است که فقط می‌گوییم «RouterOS من 7 است». برای عیب‌یابی Container باید نسخه دقیق را بدانید؛ زیرا رفتار Container در نسخه‌های مختلف 7.x یکسان نیست.

/system resource print

همچنین می‌توانید اطلاعات Packageها را بررسی کنید:

/system package print

اگر RouterOS و Package مربوط به Container هم‌نسخه نیستند، قبل از هر اقدام دیگری باید این موضوع را اصلاح کنید.

مرحله دوم؛ وضعیت Container را ببینید

دستور زیر یکی از مهم‌ترین دستورات برای پیدا کردن علت مشکل است:

/container print detail

به فیلدهای name، image/tag، interface، root-dir، cmd، entrypoint، status و logging توجه کنید.

اگر Container در وضعیت stopped قرار دارد، هنوز به معنی خراب بودن Image نیست. ابتدا باید مشخص شود Container هنگام Start چه خطایی تولید می‌کند.

خطای no command specified یعنی چه؟

یکی از مهم‌ترین خطاهایی که در سناریوهای گزارش‌شده پس از RouterOS 7.23 دیده شده، خطایی شبیه این است:

start failed: no command specified, set cmd or entrypoint

معنای ساده این خطا این است که RouterOS هنگام شروع Container نتوانسته دستور یا EntryPoint مورد نیاز برای اجرای فرآیند اصلی Container را پیدا یا استفاده کند.

این مسئله اهمیت زیادی دارد؛ زیرا یک Image ممکن است در Docker روی Linux معمولی کاملاً سالم باشد، اما RouterOS برای اجرای آن به اطلاعات مشخصی درباره Command یا Entrypoint نیاز داشته باشد.

بررسی cmd

ابتدا مقدار Command را بررسی کنید:

/container print detail where name="نام-container"

به جای نام-container نام واقعی Container خود را قرار دهید.

بررسی EntryPoint

اگر Image دارای EntryPoint مشخصی است، بررسی کنید RouterOS آن را به شکل صحیح شناسایی کرده باشد. در برخی گزارش‌های مربوط به 7.23.1، کاربران با Override کردن EntryPoint توانسته‌اند Container را دوباره اجرا کنند.

/container set [find name="نام-container"] entrypoint="start.sh"

البته نام فایل باید دقیقاً با فایل موجود در Image یکسان باشد. اگر فایل در مسیر دیگری قرار دارد، باید مسیر صحیح آن را مشخص کنید.

یک مشکل مهم دیگر؛ تغییر رفتار cmd در RouterOS 7.23

یکی از Regressionهای گزارش‌شده در RouterOS 7.23 مربوط به تغییر نوع رفتار Property مربوط به cmd است. طبق گزارش فنی کاربران، در نسخه‌های 7.22.1 و 7.22.2 مقدار cmd به شکل String رفتار می‌کرد، اما در نسخه‌های 7.23 به ساختاری Array-مانند تغییر رفتار داده و وجود کاما در بعضی Commandها می‌تواند باعث Split شدن ناخواسته مقدار شود.

این موضوع زمانی مهم می‌شود که یک برنامه داخل Container انتظار داشته باشد کاما بخشی از یک Argument باشد؛ برای مثال برنامه‌ای که چند DNS Server را با کاما دریافت می‌کند.

در چنین شرایطی ممکن است تنظیمات روی نسخه قبلی درست باشد، اما بعد از ارتقا، Command دیگر دقیقاً همان چیزی نباشد که برنامه انتظار دارد.

چطور این مشکل را پیدا کنیم؟

ابتدا Export مربوط به Container را مشاهده کنید:

/container export

اگر Command شما دارای کاما است، باید آن را با دقت بررسی کنید و ببینید آیا کاما واقعاً بخشی از یک Argument بوده یا RouterOS آن را به‌عنوان جداکننده تفسیر کرده است.

راهکار اول؛ Container را بدون حذف Image بررسی کنید

یکی از اشتباهات رایج این است که کاربر بلافاصله Container را حذف می‌کند. این کار ممکن است اطلاعات، Volume یا تنظیمات مهمی را از بین ببرد.

قبل از حذف Container، اطلاعات آن را ذخیره کنید:

/container export file=container-backup

سپس Configuration مربوط به Container را با وضعیت فعلی مقایسه کنید.

راهکار دوم؛ فعال کردن Logging برای دیدن خطای واقعی

اگر Container سریع Start و Stop می‌شود، فعال کردن Logging می‌تواند اطلاعات بسیار بیشتری در اختیار شما قرار دهد.

/container set [find name="نام-container"] logging=yes

سپس Container را Start کنید و Log RouterOS را بررسی کنید:

/container start [find name="نام-container"]
/log print

اگر برنامه داخل Container بلافاصله Crash شود، Log برنامه معمولاً بهتر از حدس زدن مشکل به شما نشان می‌دهد که مسئله از EntryPoint، Permission، فایل Configuration، Architecture یا Network است.

راهکار سوم؛ Architecture Image را بررسی کنید

Container Image باید با معماری Router شما سازگار باشد. برای مثال Image مربوط به amd64 را نمی‌توان به‌صورت عادی روی Router مبتنی بر ARM32 اجرا کرد.

برای CHR و x86 معمولاً باید Image مناسب AMD64 انتخاب شود. برای Routerهای ARM64 نیز باید Image دارای معماری ARM64 باشد.

برای مشاهده اطلاعات سخت‌افزار:

/system resource print

اگر Image قبل از ارتقا کار می‌کرد اما بعد از ارتقا کار نمی‌کند، Architecture تنها متهم نیست؛ با این حال باید آن را در فرآیند عیب‌یابی حذف کنید.

راهکار چهارم؛ فضای ذخیره‌سازی را بررسی کنید

Containerها به فضای ذخیره‌سازی مناسبی نیاز دارند. MikroTik توصیه می‌کند Containerها روی Storage خارجی مناسب اجرا شوند و برای عملیات Extract و Read/Write سنگین، دیسک سریع استفاده شود.

/disk print

راهکار پنجم؛ فعال بودن Container Mode را بررسی کنید

قابلیت Container در RouterOS به‌صورت پیش‌فرض محدود است و باید Device Mode مناسب فعال شده باشد.

/system device-mode print

در صورت نیاز، وضعیت Container Mode را بررسی کنید. فعال‌سازی این قابلیت ممکن است به تأیید فیزیکی یا Reboot نیاز داشته باشد؛ بنابراین بدون بررسی وضعیت فعلی، دستور تغییر را اجرا نکنید.

راهکار ششم؛ Package مربوط به Container را بررسی کنید

Container در RouterOS یک Package جداگانه دارد. اگر Package نصب نشده باشد یا نسخه Package با RouterOS هماهنگ نباشد، Container به شکل صحیح کار نخواهد کرد.

/system package print

در خروجی باید Package مربوط به Container را پیدا کنید. در صورت نصب Package جداگانه، نسخه آن باید با نسخه RouterOS هماهنگ باشد.

مشکل شبکه نیست؟ قبل از تغییر Firewall این موضوع را بررسی کنید

گاهی Container Start نمی‌شود و کاربر بلافاصله سراغ Firewall و NAT می‌رود؛ در حالی که Container اصلاً به مرحله اجرای سرویس نرسیده است.

اگر خروجی شما خطایی مانند no command specified دارد، اول باید Command و EntryPoint را بررسی کنید. تنظیم NAT زمانی معنا پیدا می‌کند که فرآیند داخل Container واقعاً در حال اجرا باشد.

بررسی وضعیت Interface مجازی

در صورتی که Container اجرا می‌شود اما از شبکه قابل دسترسی نیست، VETH را بررسی کنید:

/interface veth print detail

سپس IP و Gateway مربوط به شبکه Container را بررسی کنید:

/ip address print detail
/ip route print detail

اگر Container اجرا می‌شود ولی اینترنت ندارد چه کنیم؟

این سناریو با «Container اجرا نمی‌شود» تفاوت دارد. اگر Status برابر running است اما سرویس داخل Container به اینترنت دسترسی ندارد، باید DNS، Route، NAT، Gateway و Firewall را بررسی کنید.

یک تفاوت مهم بین Container و App در RouterOS 7.23

RouterOS 7.23 علاوه بر Container معمولی، سیستم App را نیز توسعه داده است. Appها می‌توانند یک یا چند Container را همراه با تنظیمات مورد نیاز اجرا کنند.

بنابراین اگر Container شما از طریق App ایجاد شده است، فقط /container را بررسی نکنید. وضعیت App، YAML و تنظیمات مربوط به آن نیز اهمیت دارد.

/app print
/app settings print

در RouterOS 7.23 قابلیت‌های جدیدی برای Appها اضافه شد؛ از جمله کنترل دسترسی خروجی شبکه Containerها با گزینه network-outgoing-access. بنابراین در Appهای جدید باید این بخش را نیز در نظر گرفت.

آیا Downgrade به نسخه قدیمی راه‌حل است؟

Downgrade می‌تواند برای تست تشخیصی مفید باشد، اما نباید اولین واکنش شما باشد. اگر Container قبل از ارتقا کار می‌کرد و بعد از ارتقا متوقف شده است، مقایسه نسخه قبلی و جدید می‌تواند کمک کند بفهمید مشکل از تغییر رفتار RouterOS است یا از Configuration.

قبل از Downgrade حتماً Backup و Export کامل تهیه کنید و سازگاری نسخه مقصد با Configuration فعلی را بررسی کنید.

RouterOS 7.23.4 چه تغییری در Container داشت؟

این بخش برای عیب‌یابی امروز بسیار مهم است. در Changelog مربوط به RouterOS 7.23.4، MikroTik چندین اصلاح مرتبط با Container منتشر کرده است؛ از جمله اصلاح رفتار EntryPoint و Shell Override، اصلاح محاسبه اندازه Layer، تشخیص Containerهایی که توسط Out-of-Memory Killer متوقف شده‌اند و چندین تغییر دیگر.

بنابراین اگر روی یکی از نسخه‌های اولیه 7.23 هستید، صرفاً با عنوان «Container در 7.23 خراب است» نتیجه‌گیری نکنید. ابتدا نسخه دقیق خود را مشخص کنید و Changelog همان نسخه را بررسی کنید.

اگر Container به دلیل کمبود RAM متوقف می‌شود

همه مشکلات بعد از ارتقا الزاماً Bug نیستند. Containerها به RAM و Storage نیاز دارند و در صورت فشار حافظه ممکن است فرآیند داخل Container متوقف شود.

در نسخه‌های جدید RouterOS امکانات بیشتری برای کنترل مصرف حافظه Container اضافه شده است. در صورت استفاده از سرویس‌هایی مانند Home Assistant، Nextcloud، Ollama یا برنامه‌های سنگین، مقدار RAM بسیار مهم است.

/container print stats

اگر نسخه RouterOS شما از نمایش وضعیت حافظه Container پشتیبانی می‌کند، مصرف واقعی را بررسی کنید. در نسخه‌های جدیدتر قابلیت‌های بیشتری برای Memory Limit و تشخیص OOM اضافه شده است.

اگر Container بعد از چند ثانیه خاموش می‌شود

این حالت معمولاً نشان می‌دهد Container توانسته تا مرحله اجرای Process اصلی پیش برود اما برنامه داخل آن با خطا خارج شده است.

سه مورد را در اولویت قرار دهید:

اگر Log برنامه نشان دهد Process اصلی با Exit Code خاصی خارج شده، باید همان Exit Code و پیام برنامه را بررسی کنید؛ نه اینکه صرفاً RouterOS را مقصر بدانید.

یک چک‌لیست کامل برای رفع مشکل Container در RouterOS 7.23

منابع رسمی برای بررسی تغییرات RouterOS و Container

برای بررسی تغییرات نسخه‌های مختلف، بهتر است همیشه به مستندات و Changelog رسمی MikroTik مراجعه کنید:

مستندات رسمی MikroTik درباره Container

مستندات رسمی Device Mode در RouterOS

Changelog رسمی RouterOS

انجمن رسمی MikroTik؛ بخش Container

اگر مشکل Container با این روش‌ها حل نشد

اگر بعد از بررسی EntryPoint، Command، Architecture، Package، Storage، RAM و Log هنوز Container اجرا نمی‌شود، بهتر است Configuration را از ابتدا حذف نکنید. اطلاعات زیر را جمع‌آوری کنید:

جمع‌بندی؛ چرا Container بعد از RouterOS 7.23 اجرا نمی‌شود؟