زامبی‌ها در کانتینر! چرا اپلیکیشن شما هرگز نباید PID 1 باشد؟احتمالاً بارها دیده‌اید که یک Pod در کوبرنتیز هنگام آپدیت شدن، دقیقاً ۳۰ ثانیه در وضعیت Terminating گیر می‌کند و بعد به زور کشته می‌شود. یا اینکه سرورهای شما به تدریج با خطای Resource temporarily unavailable (کمبود PID) از کار می‌افتند.
مشکل کجاست؟در سیستم‌عامل لینوکس، اولین پراسسی که اجرا می‌شود شناسه PID 1 را می‌گیرد (مثل systemd). این پراسسِ پدر، دو وظیفه حیاتی دارد: 1. انتقال سیگنال‌های سیستم‌عامل (مثل SIGTERM برای خاموشی امن). 2. پاکسازی لاشه پراسس‌های فرزند که کارشان تمام شده (Reaping Zombie Processes).
وقتی در داکرفایل اپلیکیشن خود (مثلاً یک سرویس Node.js یا Java) را مستقیماً اجرا می‌کنید، این اپلیکیشن PID 1 می‌شود! اما برنامه‌های ما برای مدیریت زامبی‌ها برنامه‌نویسی نشده‌اند.فاجعه چه زمانی رخ می‌دهد؟پراسس‌های مُرده روی هم تلنبار می‌شوند و به عنوان “زامبی” در پس‌زمینه باقی می‌مانند
تا جایی که محدودیت PID سرور پر می‌شود. همچنین هنگام خاموش شدن، اپلیکیشن سیگنال SIGTERM را هندل نمی‌کند، کوبرنتیز ۳۰ ثانیه صبر می‌کند و در نهایت با SIGKILL کانتینر را بی‌رحمانه می‌کشد (که می‌تواند منجر به خرابی دیتابیس یا از دست رفتن ریکوئست‌ها شود).
راه‌حل طلایی:هرگز اپلیکیشن را به عنوان PID 1 اجرا نکنید. از یک “Init System”بسیار سبک مخصوص کانتینر مانند tini یا dumb-init استفاده کنید:# بجای این حالت غلط:ENTRYPOINT ["node", "app.js"]# از tini استفاده کنید:RUN apk add --no-cache tiniENTRYPOINT ["/sbin/tini", "--"]CMD ["node", "app.js"]
(نکته: در Docker Compose می‌توانید فقط با اضافه کردن init: true این مشکل را حل کنید).
ا این کار tini به عنوان PID 1 اجرا می‌شود، زامبی‌ها را پاکسازی می‌کند و سیگنال خاموشی را به درستی به اپلیکیشن شما پاس می‌دهد تا Graceful Shutdown داشته باشید.
21:45 - 15 May 2026