خطای No space left on device در لینوکس معمولاً وقتی دیده می‌شود که برنامه‌ای نتواند روی فایل‌سیستم چیزی بنویسد. ظاهر خطا ساده است، اما علت آن همیشه فقط پر بودن دیسک نیست. ممکن است خود پارتیشن هدف پر شده باشد، inodeها تمام شده باشند، یک فایل لاگ بسیار بزرگ فضا را گرفته باشد، یا حتی فایلی حذف شده باشد اما چون هنوز توسط یک فرایند باز است، فضای آن آزاد نشود.
برای رفع این خطا باید به‌جای حذف شتاب‌زده فایل‌ها، مشخص کنید دقیقاً کدام منبع تمام شده است: بلوک‌های دیسک، inodeها، فضای یک mount point خاص، یا فضای موقت. رویکرد درست این است که ابتدا وضعیت را مشاهده کنید، سپس منبع مصرف را پیدا کنید و در پایان علت ریشه‌ای را برطرف کنید تا خطا دوباره تکرار نشود.
اول مشخص کنید کدام فضا تمام شده است
دو بررسی پایه در شروع کار ضروری است: ظرفیت دیسک و تعداد inodeها. این دو خروجی معمولاً مشخص می‌کنند مشکل از کجاست.
df -h
df -iخروجی df -h نشان می‌دهد کدام فایل‌سیستم از نظر حجم پر شده است. خروجی df -i هم نشان می‌دهد آیا inodeها تمام شده‌اند یا نه. اگر inodeها به سقف رسیده باشند، حتی با وجود چند گیگابایت فضای خالی هم امکان ساخت فایل جدید وجود ندارد.
به ستون mount point دقت کنید. خیلی وقت‌ها ریشه سیستم فضای خالی دارد، اما مثلاً /var، /tmp یا /home روی پارتیشن جداگانه قرار دارد و همان بخش پر شده است.
مصرف را در همان فایل‌سیستم ردیابی کنید
بعد از پیدا کردن پارتیشن مشکل‌دار، باید ببینید کدام مسیر بیشترین فضا را گرفته است. برای این کار از du استفاده کنید، اما فقط در همان فایل‌سیستم بمانید تا mountهای دیگر نتیجه را گمراه نکنند.
du -xhd1 /var | sort -h
du -xhd1 / | sort -hاگر مشخص شد مثلاً /var پر است، بررسی را عمیق‌تر کنید:
du -xhd1 /var/log | sort -h
du -xhd1 /var/lib | sort -hگزینه -x باعث می‌شود فقط همان فایل‌سیستم بررسی شود. این نکته مهم است، چون بدون آن ممکن است دایرکتوری‌های mount شده از جاهای دیگر وارد خروجی شوند و مسیر عیب‌یابی را منحرف کنند.
سناریوهای رایج و روش رفع
۱) لاگ‌ها بزرگ شده‌اند
پوشه /var/log یکی از رایج‌ترین محل‌ها برای پر شدن فضا است. قبل از حذف، ابتدا نوع فایل را بشناسید. حذف بی‌دقت فایل‌های لاگ می‌تواند روند عیب‌یابی امنیتی یا سرویس‌دهی را مختل کند.
find /var/log -type f -size +100M -lsاگر فایل لاگ بزرگی پیدا کردید، به‌جای پاک کردن کورکورانه، ابتدا بررسی کنید آیا سرویس مربوطه از rotation پشتیبانی می‌کند یا نه. در برخی موارد می‌توانید فایل را truncate کنید تا فضا آزاد شود و سرویس همچنان فایل را باز نگه دارد:
: > /var/log/app.logاین روش از حذف مستقیم امن‌تر است، چون inode همان فایل حفظ می‌شود. البته باید مطمئن باشید سرویس به truncation حساس نیست و لاگ فعلی برای بررسی بعدی لازم نیست.
۲) فایل حذف شده اما فضا آزاد نشده است
اگر فایلی حذف شده ولی هنوز توسط یک فرایند باز است، فضای آن تا زمان بسته شدن file descriptor آزاد نمی‌شود. این وضعیت با lsof قابل شناسایی است:
lsof +L1در این خروجی فایل‌هایی را می‌بینید که تعداد لینک آن‌ها صفر شده اما هنوز باز هستند. در چنین حالتی یا سرویس را به‌درستی restart کنید، یا اگر امکان دارد همان فرایند را متوقف کنید تا descriptor بسته شود.
نکته مهم: از کشتن عجولانه فرایندهای حیاتی مانند پایگاه داده یا reverse proxy بدون برنامه نگهداری و بررسی وابستگی‌ها خودداری کنید.
۳) inodeها تمام شده‌اند
پر شدن inode معمولاً در سرورهایی رخ می‌دهد که تعداد زیادی فایل کوچک تولید می‌کنند؛ مثلاً cache، session، queue یا فایل‌های موقت. اگر df -i نشان داد inodeها تمام شده‌اند، به‌جای دنبال کردن فایل‌های بزرگ باید تعداد فایل‌ها را بررسی کنید.
find /var -xdev -type f | wc -l
find /tmp -xdev -type f | wc -lبرای پیدا کردن مسیرهای پر از فایل کوچک:
find /var -xdev -printf '%hn' | sort | uniq -c | sort -n | tailدر این وضعیت حذف یا پاک‌سازی ساختاریافته فایل‌های کوچک مؤثرتر از حذف چند فایل بزرگ است.
۴) فضای /tmp یا /var/tmp پر شده است
بسیاری از برنامه‌ها هنگام build، unzip، upload یا پردازش فایل از /tmp استفاده می‌کنند. ممکن است خطا هنگام نصب بسته یا اجرای یک برنامه ظاهر شود، در حالی که ریشه سیستم هنوز جا دارد.
df -h /tmp
ls -lah /tmp | headدر سرورهای چندکاربره یا سرویس‌های وب، پاک‌سازی /tmp باید با احتیاط انجام شود. فایل‌هایی که هنوز در حال استفاده هستند را حذف نکنید. اگر لازم است، ابتدا مالک و زمان تغییر را بررسی کنید:
find /tmp -xdev -type f -mtime +1 -ls | head -50۵) مصرف غیرعادی در Docker یا ابزارهای کانتینری
اگر سرور از کانتینر استفاده می‌کند، مصرف فضا ممکن است در imageها، لایه‌ها، volumeها یا لاگ کانتینرها جمع شده باشد. محل نگهداری بسته به تنظیمات سیستم متفاوت است، اما معمولاً زیر /var/lib دیده می‌شود. قبل از حذف، مطمئن شوید object مورد نظر توسط سرویس فعال استفاده نمی‌شود.
اگر مسیرهای حجیم در /var/lib دیده می‌شوند، ابتدا با ابزار خود همان runtime وضعیت را بررسی کنید و سپس cleanup را طبق سیاست نگهداری انجام دهید. حذف دستی فایل‌های داخلی storage کانتینر بدون شناخت ساختار آن می‌تواند به خراب شدن داده یا از کار افتادن سرویس منجر شود.
وقتی نمی‌دانید برنامه در کجا خطا می‌دهد
گاهی پیام خطا فقط در لاگ برنامه دیده می‌شود و معلوم نیست کدام mount point هدف نوشتن بوده است. در این حالت سه نقطه را بررسی کنید:
- مسیر فایل مقصد که برنامه در آن write می‌کند
- دایرکتوری موقت مانند
/tmpیا متغیر محیطیTMPDIR - پوشه‌های لاگ، cache و upload مربوط به همان سرویس
مثلاً یک برنامه وب ممکن است فایل را در /tmp بسازد و بعد به /var/www/app/storage منتقل کند. بنابراین هر دو مسیر باید فضای کافی داشته باشند.
حذف امن‌تر از حذف سریع است
در شرایط بحرانی وسوسه حذف دسته‌ای فایل‌ها زیاد است، اما این کار می‌تواند وضعیت را بدتر کند. برای کاهش ریسک، این ترتیب را رعایت کنید:
- اول از فایل‌های قابل بازتولید شروع کنید؛ مثل cacheها یا artifactهای موقت
- بعد سراغ لاگ‌های قدیمی rotate شده بروید، نه لاگ فعال
- برای سرویس‌های حساس، قبل از حذف از مسیر و مالک فایل مطمئن شوید
- اگر داده کاربردی یا پایگاه داده درگیر است، حذف مستقیم آخرین گزینه باشد
در بسیاری از موارد، انتقال موقت فایل‌های حجیم به فایل‌سیستم دیگر از حذف مستقیم کم‌خطرتر است، چون امکان بازگردانی را حفظ می‌کند.
مثال مرحله‌به‌مرحله
فرض کنید برنامه‌ای هنگام آپلود فایل خطای No space left on device می‌دهد.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 40G 18G 20G 48% /
/dev/sda2 10G 10G 0 100% /varاینجا مشکل روی /var است، نه ریشه سیستم. حالا مصرف داخل /var را می‌بینید:
du -xhd1 /var | sort -h
1.2G /var/tmp
7.8G /var/logدر ادامه فایل‌های بزرگ لاگ را پیدا می‌کنید:
find /var/log -type f -size +500M -lsاگر یک فایل لاگ فعال چند گیگابایتی پیدا شد، به‌جای rm می‌توانید آن را truncate کنید:
: > /var/log/myapp/error.logسپس دوباره فضا را بررسی کنید:
df -h /varاگر فضا آزاد نشد، احتمال فایل حذف‌شده اما باز مطرح است:
lsof +L1 | grep /varدر این مثال، اگر فرایند برنامه هنوز فایل قدیمی را باز نگه داشته باشد، restart کنترل‌شده سرویس معمولاً فضا را واقعاً آزاد می‌کند.
نکات امنیتی در زمان رفع مشکل
- دستورات پاک‌سازی را با مسیرهای صریح اجرا کنید و از الگوهای مبهم مانند wildcardهای خطرناک در مسیرهای سیستمی پرهیز کنید.
- قبل از حذف فایل‌های ناشناس در
/tmpیا/var/tmp، مالک و فرایند مرتبط را بررسی کنید؛ ممکن است متعلق به سرویس فعال باشند. - اگر سرور چندکاربره است، استفاده از
duوfindروی دایرکتوری کاربران باید با رعایت دسترسی‌ها و حداقل دسترسی لازم انجام شود. - فایل‌های لاگ را بدون توجه به نیازهای ثبت رویداد و بررسی رخدادها حذف نکنید. در بعضی محیط‌ها نگهداری لاگ بخشی از الزامات عملیاتی است.
- اگر فضا ناگهان پر شده، احتمال خطای برنامه، loop در logging یا تولید کنترل‌نشده فایل را بررسی کنید؛ صرف آزاد کردن فضا بدون رفع علت اصلی کافی نیست.
پیشگیری از تکرار خطا
پس از رفع فوری مشکل، بهتر است علت ساختاری را برطرف کنید. چند اقدام مؤثر:
- تنظیم rotation برای لاگ‌ها و بازبینی اندازه و تعداد فایل‌های نگهداری‌شده
- پاک‌سازی دوره‌ای cache، session و فایل‌های موقت با سیاست روشن
- مانیتور کردن جداگانه فضای
/،/var،/tmpو inodeها - بازبینی محل ذخیره uploadها، backupهای محلی و dumpهای موقت
- اطمینان از اینکه برنامه در شرایط خطا، بی‌نهایت لاگ یا فایل موقت تولید نمی‌کند
جمع‌بندی
رفع No space left on device در سرور لینوکس با یک سؤال شروع می‌شود: دقیقاً چه چیزی تمام شده است؟ حجم دیسک، inode، یا فضای یک mount point خاص؟ با df -h و df -i شروع کنید، با du مسیر پرمصرف را پیدا کنید، و در صورت نیاز فایل‌های حذف‌شده اما باز را با lsof +L1 بررسی کنید. پاک‌سازی هدفمند و امن، از حذف عجولانه بسیار بهتر است؛ چون هم سرویس پایدارتر می‌ماند و هم احتمال از دست رفتن داده کمتر می‌شود.
دیدگاه‌ها