--blkio-weight=weight

وزن نسبی Block IO. مقدار weight مقداری بین 10 و 1000 است.

این گزینه در سیستم‌های بدون ریشه (rootless) مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--blkio-weight-device=device:weight

وزن نسبی دستگاه Block IO.

--cpu-period=limit

تنظیم دوره CPU برای زمان‌بند کاملاً منصفانه (CFS) که مدت زمانی بر حسب میکروثانیه است. هنگامی که سهمیه CPU کانتینر مصرف شود، تا زمان پایان دوره جاری برای اجرا زمان‌بندی نخواهد شد. مقدار پیش‌فرض 100000 میکروثانیه است.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--cpu-quota=limit

محدود کردن سهمیه زمان‌بند کاملاً منصفانه (CFS) پردازنده.

مصرف پردازنده کانتینر را محدود می‌کند. به‌طور پیش‌فرض، کانتینرها با تمام توان منابع CPU اجرا می‌شوند. محدودیت عددی بر حسب میکروثانیه است. اگر عددی تعیین شود، کانتینر مجاز است تا پایان دوره زمانی CPU (قابل کنترل با --cpu-period) از همان میزان زمان CPU استفاده کند.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--cpu-rt-period=microseconds

محدود کردن دوره زمانی بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

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

این گزینه تنها در سیستم‌های دارای ریشه (rootful) مبتنی بر cgroups V1 پشتیبانی می‌شود.

--cpu-rt-runtime=microseconds

محدود کردن زمان اجرای بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

مصرف پردازنده بی‌درنگ کانتینر را محدود می‌کند. این گزینه به هسته اعلام می‌کند میزان زمانی را که وظایف بی‌درنگ می‌توانند در یک دوره معین CPU مصرف کنند محدود نماید. به عنوان مثال: دوره‌ای معادل 1,000,000 میکروثانیه و زمان اجرای 950,000 میکروثانیه به این معنی است که کانتینر می‌تواند ۹۵٪ از پردازنده در دسترس را مصرف کند و ۵٪ باقی‌مانده را برای وظایف با اولویت عادی بگذارد.

مجموع تمام زمان‌های اجرا در میان کانتینرها نمی‌تواند از مقدار اختصاص‌یافته به cgroup والد تجاوز کند.

این گزینه تنها در سیستم‌های دارای ریشه مبتنی بر cgroups V1 پشتیبانی می‌شود.

--cpu-shares, -c=shares

سهم‌های پردازنده (وزن نسبی).

به‌طور پیش‌فرض، تمام کانتینرها نسبت برابری از چرخه‌های CPU دریافت می‌کنند. این نسبت را می‌توان با تغییر وزن سهم CPU کانتینر نسبت به وزن ترکیبی تمام کانتینرهای در حال اجرا تغییر داد. وزن پیش‌فرض 1024 است.

این نسبت تنها زمانی اعمال می‌شود که فرایندهای فشرده از نظر مصرف پردازنده در حال اجرا باشند. هنگامی که وظایف در یک کانتینر بیکار هستند، کانتینرهای دیگر می‌توانند از زمان باقی‌مانده CPU استفاده کنند. مقدار واقعی زمان CPU بسته به تعداد کانتینرهای در حال اجرا روی سیستم متغیر است.

برای نمونه، سه کانتینر را در نظر بگیرید: یکی دارای cpu-share معادل 1024 و دو تای دیگر دارای تنظیم 512 هستند. هنگامی که فرایندها در هر سه کانتینر تلاش کنند از ۱۰۰٪ CPU استفاده کنند، کانتینر اول ۵۰٪ از کل زمان پردازنده را دریافت می‌کند. اگر کانتینر چهارمی با cpu-share معادل 1024 افزوده شود، کانتینر اول تنها ۳۳٪ از CPU را دریافت خواهد کرد. کانتینرهای باقی‌مانده ۱۶.۵٪، ۱۶.۵٪ و ۳۳٪ از CPU را دریافت می‌کنند.

در یک سیستم چند‌هسته‌ای، سهم‌های زمان پردازنده روی تمام هسته‌های CPU توزیع می‌شوند. حتی اگر یک کانتینر به کمتر از ۱۰۰٪ کل زمان پردازنده محدود شده باشد، می‌تواند از ۱۰۰٪ هر یک از هسته‌های منفرد پردازنده استفاده کند.

برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر کانتینر C0 با --cpu-shares=512 در حال اجرای یک فرایند راه‌اندازی شود، و کانتینر دیگری به نام C1 با --cpu-shares=1024 در حال اجرای دو فرایند باشد، این می‌تواند منجر به تقسیم سهم‌های CPU به شکل زیر شود:

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--cpus=number

تعداد CPUها. مقدار پیش‌فرض 0.0 است که به معنای عدم اعمال محدودیت است. این گزینه کوتاه‌نویسی برای --cpu-period و --cpu-quota است، بنابراین نمی‌توان آن را هم‌زمان با --cpu-period یا --cpu-quota تعیین کرد.

در برخی سیستم‌ها، تغییر محدودیت‌های CPU ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--cpuset-cpus=number

پردازنده‌های مجاز برای اجرا. می‌تواند به عنوان یک فهرست جداشده با کاما (مانند 0,1)، به عنوان یک بازه (مانند 0-3)، یا هر ترکیبی از آن‌ها (مانند 0-3,7,11-15) مشخص شود.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--cpuset-mems=nodes

گره‌های حافظه (MEMها) مجاز برای اجرا (0-3، 0,1). تنها در سیستم‌های با معماری NUMA مؤثر است.

اگر چهار گره حافظه در سیستم وجود داشته باشد (0-3)، استفاده از --cpuset-mems=0,1 موجب می‌شود فرایندهای کانتینر تنها از حافظه دو گره اول استفاده کنند.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--device-read-bps=path:rate

محدود کردن نرخ خواندن (بر حسب بایت بر ثانیه) از یک دستگاه (مانند --device-read-bps=/dev/sda:1mb).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--device-read-iops=path:rate

محدود کردن نرخ خواندن (بر حسب عملیات ورودی/خروجی در ثانیه) از یک دستگاه (مانند --device-read-iops=/dev/sda:1000).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--device-write-bps=path:rate

محدود کردن نرخ نوشتن (بر حسب بایت بر ثانیه) در یک دستگاه (مانند --device-write-bps=/dev/sda:1mb).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--device-write-iops=path:rate

محدود کردن نرخ نوشتن (بر حسب عملیات ورودی/خروجی در ثانیه) در یک دستگاه (مانند --device-write-iops=/dev/sda:1000).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیرریشه مجاز نباشد. برای جزئیات بیشتر، ببینید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--env, -e=env

افزودن یک مقدار (مانند env=value) به کانتینر. می‌تواند چندین بار استفاده شود. اگر این مقدار از قبل در کانتینر وجود داشته باشد، جایگزین می‌شود. برای حذف یک متغیر محیطی از کانتینر، از گزینه --unsetenv استفاده کنید.

توجه داشته باشید که به‌روزرسانی‌های متغیرهای محیطی تنها پس از شروع بعدی بر فرایند اصلی کانتینر تأثیر می‌گذارند.

--health-cmd="command" | '["command", arg1 , ...]'

تنظیم یا تغییر دستور بررسی سلامت برای یک کانتینر. این دستور دستوری است که داخل کانتینر اجرا می‌شود و سلامت کانتینر را تعیین می‌کند. این دستور برای اعمال سایر گزینه‌های بررسی سلامت الزامی است. مقدار none بررسی‌های سلامت موجود را غیرفعال می‌کند.

چندین گزینه می‌توانند در قالب یک آرایه JSON ارسال شوند؛ در غیر این صورت، دستور به عنوان آرگومانی برای /bin/sh -c تفسیر می‌شود.

نکته: مقادیر پیش‌فرض استفاده می‌شوند حتی اگر بررسی سلامت در ایمیج پیکربندی شده باشد.

--health-interval=interval

تنظیم یک بازه زمانی برای بررسی‌های سلامت. بازه disable منجر به عدم تنظیم خودکار تایمر می‌شود. مقدار پیش‌فرض 30s است.

نکته: این پارامتر پیکربندی مرتبط با بررسی سلامت از ایمیج را بازنویسی می‌کند.

تغییر این تنظیم، تایمر را بازنشانی می‌کند.

--health-log-destination=directory_path

تنظیم مقصد گزارش HealthCheck. مسیر دایرکتوری، local یا events_logger (در حالت local از فایل وضعیت کانتینر استفاده می‌شود) (پیش‌فرض: local)

• local: (پیش‌فرض) گزارش‌های HealthCheck در کانتینرهای overlay ذخیره می‌شوند. (برای نمونه: $runroot/healthcheck.log)
• directory: یک فایل گزارش با نام <container-ID>-healthcheck.log حاوی گزارش‌های HealthCheck در دایرکتوری مشخص‌شده ایجاد می‌کند.
• events_logger: گزارش با سازوکار ثبت لاگ تعیین‌شده توسط events_logger نوشته خواهد شد. این گزینه همچنین لاگ را در یک دایرکتوری پیش‌فرض ذخیره می‌کند تا کارایی سیستم در حضور تعداد بالای لاگ‌ها حفظ شود.

هشدار: تغییر این تنظیم ممکن است باعث از دست رفتن لاگ‌های قبلی شود.

--health-max-log-count=number of stored logs

تنظیم حداکثر تعداد تلاش‌ها در فایل لاگ HealthCheck. (مقدار '0' به معنای تعداد نامحدود تلاش‌ها در فایل لاگ است) (پیش‌فرض: 5 تلاش)

--health-max-log-size=size of stored logs

تنظیم حداکثر طول کاراکترهای لاگ HealthCheck ذخیره‌شده. (مقدار "0" به معنای طول نامحدود لاگ است) (پیش‌فرض: 500 کاراکتر)

--health-on-failure=action

عملی که پس از انتقال کانتینر به وضعیت ناسالم باید انجام شود. مقدار پیش‌فرض none است.

• none: هیچ اقدامی انجام نده.
• kill: کانتینر را از بین ببر (kill).
• restart: کانتینر را بازراه‌اندازی کن (restart). اقدام restart را با پرچم --restart ترکیب نکنید. هنگام اجرا در یک واحد systemd، استفاده از اقدام kill یا stop را در نظر بگیرید تا از خط‌مشی بازراه‌اندازی خود systemd استفاده شود.
• stop: کانتینر را متوقف کن (stop).

--health-retries=retries

تعداد دفعات تلاش مجاز پیش از آنکه یک بررسی سلامت ناسالم تلقی شود. مقدار پیش‌فرض 3 است.

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

--health-start-period=period

زمان اولیه مورد نیاز کانتینر برای بالا آمدن و آماده‌سازی. مقدار می‌تواند در قالب زمانی مانند 2m3s بیان شود. مقدار پیش‌فرض 0s است.

نکته: دستور بررسی سلامت به محض شروع کانتینر اجرا می‌شود؛ اگر بررسی سلامت موفقیت‌آمیز باشد وضعیت سلامت کانتینر به healthy به‌روزرسانی می‌شود. اما اگر بررسی سلامت با شکست روبرو شود، وضعیت سلامت تا زمانی که بررسی سلامت موفق شود یا زمان --health-start-period به پایان برسد در حالت starting باقی می‌ماند. اگر دستور بررسی سلامت پس از اتمام زمان --health-start-period شکست بخورد، وضعیت سلامت به unhealthy به‌روزرسانی خواهد شد. دستور بررسی سلامت به صورت دوره‌ای بر اساس مقدار --health-interval اجرا می‌شود.

نکته: این پارامتر پیکربندی مرتبط با بررسی سلامت از ایمیج را بازنویسی می‌کند.

--health-startup-cmd="command" | '["command", arg1 , ...]'

تنظیم دستور بررسی سلامت آغازین برای یک کانتینر. این دستور داخل کانتینر اجرا می‌شود و برای کنترل شروع بررسی سلامت عادی به کار می‌رود. هنگامی که دستور آغازین موفق شود، بررسی سلامت عادی شروع شده و بررسی سلامت آغازین متوقف می‌شود. به صورت اختیاری، اگر دستور تعداد دفعات معینی شکست بخورد، کانتینر بازراه‌اندازی می‌شود. بررسی سلامت آغازین می‌تواند برای اطمینان از این به کار رود که کانتینرهایی با مدت زمان راه‌اندازی طولانی پیش از شروع کامل به عنوان ناسالم علامت‌گذاری نشوند. بررسی‌های سلامت آغازین تنها زمانی قابل استفاده هستند که یک بررسی سلامت عادی (از ایمیج کانتینر یا گزینه --health-cmd) نیز تنظیم شده باشد.

--health-startup-interval=interval

تنظیم یک بازه زمانی برای بررسی سلامت آغازین. بازه disable منجر به عدم تنظیم خودکار تایمر می‌شود. مقدار پیش‌فرض 30s است.

تغییر این تنظیم بسته به وضعیت کانتینر، تایمر را بازنشانی می‌کند.

--health-startup-retries=retries

تعداد تلاش‌های مجاز پیش از آنکه بررسی سلامت آغازین کانتینر را بازراه‌اندازی کند. اگر روی 0 تنظیم شود، کانتینر هرگز بازراه‌اندازی نمی‌شود. مقدار پیش‌فرض 0 است.

--health-startup-success=retries

تعداد دفعات اجرای موفق مورد نیاز پیش از اینکه بررسی سلامت آغازین موفقیت‌آمیز بوده و بررسی سلامت عادی شروع شود. مقدار 0 به این معناست که هر موفقیتی بررسی سلامت عادی را آغاز می‌کند. مقدار پیش‌فرض 0 است.

--health-startup-timeout=timeout

حداکثر زمان مجاز برای تکمیل دستور بررسی سلامت آغازین پیش از آنکه به عنوان ناموفق علامت‌گذاری شود. مقدار می‌تواند در قالب زمانی مانند 2m3s بیان شود. مقدار پیش‌فرض 30s است.

--health-timeout=timeout

حداکثر زمان مجاز برای تکمیل بررسی سلامت پیش از ناموفق تلقی شدن یک بازه زمانی. مانند start-period، مقدار می‌تواند در قالب زمانی مانند 1m22s بیان شود. مقدار پیش‌فرض 30s است.

نکته: سررسید زمان (timeout) بررسی سلامت را به عنوان ناموفق علامت‌گذاری می‌کند. اگر خود دستور بررسی سلامت بیش از timeout مشخص‌شده اجرا شود، سیگنال SIGKILL به آن ارسال خواهد شد.

نکته: این پارامتر پیکربندی مرتبط با بررسی سلامت از ایمیج را بازنویسی می‌کند.

--latest, -l

به جای ارائه نام یا شناسه کانتینر، از آخرین کانتینر ایجادشده استفاده کن. نکته: آخرین کانتینر شروع‌شده می‌تواند مربوط به سایر کاربران پادمن روی ماشین میزبان باشد. (این گزینه در کلاینت راه دور پادمن، از جمله سیستم‌های مک و ویندوز (به جز WSL2) در دسترس نیست).

--memory, -m=number[unit]

محدودیت حافظه. واحد (unit) می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت)، یا g (گیبی‌بایت) باشد.

اجازه می‌دهد حافظه در دسترس کانتینر محدود شود. اگر میزبان از حافظه swap پشتیبانی کند، تنظیمات حافظه --memory می‌تواند بزرگ‌تر از رم فیزیکی باشد. اگر محدودیت 0 مشخص شود (عدم استفاده از --memory)، حافظه کانتینر محدود نمی‌شود. محدودیت واقعی ممکن است به مضربی از اندازه صفحه سیستم‌عامل گرد شود (این مقدار بسیار بزرگ است، میلیون‌ها تریلیون).

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--memory-reservation=number[unit]

حد نرم حافظه. واحد (unit) می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت)، یا g (گیبی‌بایت) باشد.

پس از تنظیم رزرو حافظه، هنگامی که سیستم رقابت بر سر حافظه یا کمبود حافظه را تشخیص دهد، کانتینرها مجبور می‌شوند مصرف خود را به اندازه رزرو خود محدود کنند. بنابراین همیشه مقدار را کمتر از --memory تنظیم کنید، در غیر این صورت حد سخت اولویت خواهد داشت. به‌طور پیش‌فرض، رزرو حافظه همان محدودیت حافظه است.

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--memory-swap=number[unit]

مقداری برابر با مجموع حافظه به علاوه سواپ (swap). واحد (unit) می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت)، یا g (گیبی‌بایت) باشد.

باید همراه با پرچم -m (--memory) استفاده شود. مقدار آرگومان باید بزرگ‌تر از مقدار
-m (--memory) باشد. به‌طور پیش‌فرض، برابر با دو برابر مقدار --memory تنظیم می‌شود.

برای فعال کردن swap نامحدود، مقدار number را روی -1 قرار دهید.

این گزینه در سیستم‌های بدون ریشه مبتنی بر cgroups V1 پشتیبانی نمی‌شود.

--memory-swappiness=number

تنظیم رفتار swappiness حافظه کانتینر. یک عدد صحیح بین 0 و 100 می‌پذیرد.

این پرچم تنها در سیستم‌های دارای ریشه (rootful) مبتنی بر cgroups V1 پشتیبانی می‌شود.

--no-healthcheck

غیرفعال کردن هرگونه بررسی سلامت تعریف‌شده برای کانتینر.

--pids-limit=limit

تنظیم محدودیت pids کانتینر. برای داشتن تعداد نامحدود pid برای کانتینر، مقدار را روی -1 قرار دهید. مقدار پیش‌فرض در سیستم‌هایی که از کنترلر cgroup با عنوان "pids" پشتیبانی می‌کنند 2048 است.

--restart=policy

خط‌مشی بازراه‌اندازی برای اعمال در زمان خروج کانتینرها. اگر کانتینر از طریق دستورات podman kill یا podman stop متوقف شود، خط‌مشی بازراه‌اندازی اعمال نخواهد شد.

مقادیر معتبر policy عبارتند از:

• no : کانتینرها را پس از خروج بازراه‌اندازی نکن
• never : مترادف برای no؛ کانتینرها را هنگام خروج بازراه‌اندازی نکن
• on-failure[:max_retries] : بازراه‌اندازی کانتینرها در صورتی که با کد خروج غیرصفر خارج شوند، با تکرار نامحدود یا تا رسیدن به سقف اختیاری max_retries
• always : بازراه‌اندازی کانتینرها هنگام خروج، بدون در نظر گرفتن وضعیت، با تکرار نامحدود
• unless-stopped : بازراه‌اندازی کانتینرها پس از خروج، مگر اینکه کانتینر صریحاً توسط کاربر متوقف شده باشد. پس از راه‌اندازی مجدد سیستم (reboot)، کانتینرهای دارای این خط‌مشی توسط podman-restart.service تنها در صورتی مجدداً راه‌اندازی می‌شوند که پیش از ریبوت صریحاً توسط کاربر متوقف نشده باشند. این با always تفاوت دارد، زیرا always کانتینرها را پس از ریبوت سیستم بدون توجه به اینکه توسط کاربر متوقف شده باشند یا خیر مجدداً راه‌اندازی می‌کند

پادمن یک فایل واحد systemd به نام podman-restart.service ارائه می‌دهد که کانتینرها را پس از ریبوت سیستم مجدداً راه‌اندازی می‌کند.

هنگام اجرای کانتینرها در سرویس‌های systemd، از قابلیت بازراه‌اندازی ارائه‌شده توسط خود systemd استفاده کنید. به عبارت دیگر، از این گزینه در واحدهای کانتینری استفاده نکنید، بلکه دستورالعمل Restart= را در بخش [Service] سیستم‌دی تنظیم نمایید. صفحات راهنمای podman-systemd.unit(5) و systemd.service(5) را ببینید.

--ulimit=option

گزینه‌های ulimit. مقادیر ulimit را داخل کانتینر تنظیم می‌کند.

گزینه --ulimit با یک حد نرم و سخت در قالب =[:] استفاده می‌شود. برای مثال:

$ podman run --ulimit nofile=1024:1024 --rm ubi9 ulimit -n 1024

مقدار -1 را برای حد نرم یا سخت تنظیم کنید تا حد به حداکثر مقدار مجاز فرایند جاری تعیین شود. در حالت rootful این مقدار معمولاً نامحدود است.

اگر nofile و nproc تعیین نشده باشند، مقدار پیش‌فرض 1048576 استفاده خواهد شد، مگر اینکه در containers.conf(5) بازنویسی شده باشد. با این وجود، اگر مقدار پیش‌فرض از حد سخت برای کاربر rootless فعلی فراتر رود، حد سخت جاری به جای آن اعمال می‌شود.

از host برای کپی کردن پیکربندی جاری از میزبان استفاده کنید.

از nproc با پرچم ulimit استفاده نکنید زیرا لینوکس از nproc برای تنظیم حداکثر تعداد فرایندهای در دسترس یک کاربر استفاده می‌کند، نه یک کانتینر.

از گزینه --pids-limit برای اصلاح کنترل cgroup به منظور محدود ساختن تعداد فرایندها در یک کانتینر استفاده کنید.

نکته: تغییرات ulimit پس از راه‌اندازی مجدد کانتینر اعمال می‌شوند.

--unsetenv=env

حذف متغیرهای محیطی از کانتینر.

توجه داشته باشید که به‌روزرسانی‌های متغیرهای محیطی تنها پس از شروع بعدی بر فرایند اصلی کانتینر تأثیر می‌گذارند.