Xử Lý Tình Trạng Full Inode Trên VPS/Server Linux – Chẩn Đoán, Dọn Dẹp & Phòng Ngừa Từ A-Z

Xử lý tình trạng full inode là việc cần làm ngay khi website báo lỗi 500, không upload được file hoặc dịch vụ không khởi động, trong khi df -h vẫn báo ổ cứng còn hàng chục GB trống. Vấn đề không nằm ở dung lượng lưu trữ mà ở inode đã cạn. Phần dưới đây đi từ cách chẩn đoán, dọn dẹp đến phòng ngừa trên VPS Linux. Nếu cần môi trường root đầy đủ để thực hành, InterData cung cấp VPS và Cloud Server với toàn quyền quản trị.

Inode là gì? Vì sao đầy inode lại gây lỗi?

Inode (index node) là cấu trúc dữ liệu mà filesystem dùng để lưu metadata của mỗi file hoặc thư mục: quyền truy cập, chủ sở hữu, kích thước, thời gian tạo/sửa và con trỏ đến các block dữ liệu trên đĩa. Mỗi file hoặc thư mục bạn tạo ra tiêu tốn đúng một inode, bất kể file nặng 1 KB hay 100 MB. Khi filesystem được format, số lượng inode đã được cố định. Bạn không thể thêm inode vào một phân vùng ext4 đang chạy mà không format lại.

Vì vậy mới có chuyện ổ cứng còn trống nhưng không tạo được file. df -h đo dung lượng block, còn df -i đo số lượng inode. Một thư mục chứa hàng triệu file session nhỏ vài chục byte có thể chiếm chưa đến 1 GB nhưng đã ngốn sạch inode của phân vùng. Kernel trả về lỗi No space left on device dù df -h vẫn báo còn trống.

Cần phân biệt full disk và full inode. Full disk là hết dung lượng block; bạn xóa file lớn là giải phóng được. Full inode là hết slot metadata; bạn phải xóa nhiều file nhỏ, có khi hàng trăm nghìn đến hàng triệu file. Nếu chưa quen quản trị VPS qua dòng lệnh, bạn có thể xem tài liệu hướng dẫn sử dụng VPS trước khi thực hành phần dọn inode bên dưới. Trường hợp full disk thuần túy, tức block hết nhưng inode vẫn thoải mái, được xử lý theo quy trình khác. Bạn xem bài xử lý lỗi VPS bị full disk để so sánh.

Cách kiểm tra và chẩn đoán inode bị đầy

Bạn cần kết nối SSH vào server với quyền root hoặc user có sudo. Nếu chưa quen thao tác kết nối, bài đăng nhập VPS qua SSH trên Windows, macOS và Linux sẽ giúp bạn thiết lập phiên làm việc trước khi chạy các lệnh bên dưới.

Bước 1: Kiểm tra tổng quan inode bằng df -i

Lệnh df -i hiển thị số inode đã dùng, còn trống và phần trăm sử dụng cho từng phân vùng. Đây là lệnh đầu tiên bạn nên chạy khi nghi ngờ full inode.

df -i -h

Kết quả trả về có dạng:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 2621440       0  100% /
tmpfs           502344      12  502332    1% /dev/shm

Cột IUse% cho biết mức sử dụng inode. Khi giá trị này đạt 100% hoặc gần 95%, bạn cần dọn ngay. Cột IFree bằng 0 là dấu hiệu rõ ràng nhất rằng filesystem đã hết inode. So sánh với df -h cùng phân vùng: nếu dung lượng block vẫn còn nhiều GB nhưng inode đã 100%, bạn đang đối mặt với full inode thuần túy, không phải full disk.

Bước 2: Xác định thư mục chiếm nhiều inode nhất

Sau khi xác nhận phân vùng nào đầy inode, bạn cần tìm thư mục nào đang chứa lượng file lớn nhất. Có hai cách tiếp cận: đếm số file trong từng thư mục cấp một, hoặc dùng du --inodes để liệt kê trực tiếp theo số inode tiêu thụ.

Cách 1: Đếm file trong từng thư mục gốc

for d in /*; do
  echo -n "$d: "
  find "$d" -xdev -type f 2>/dev/null | wc -l
done

Lệnh này duyệt từng thư mục cấp một dưới root, đếm số file bên trong và in ra kết quả. Thư mục có số lượng file lớn nhất là mục tiêu cần điều tra tiếp. Sau khi xác định được thư mục cấp một, bạn lặp lại quy trình với các thư mục con bên trong để khoanh vùng chính xác.

Cách 2: Dùng du –inodes để xếp hạng

du --inodes --max-depth=1 / 2>/dev/null | sort -n -r | head -20

Kết quả liệt kê 20 thư mục tiêu thụ nhiều inode nhất, sắp xếp giảm dần. Bạn tiếp tục chạy lệnh này trên thư mục đứng đầu để đi sâu vào các cấp con.

Cách 3: Tìm nhanh thư mục chứa nhiều file trong một cây cụ thể

find /var -xdev -type d -exec sh -c \
  'echo "$(find "$1" -maxdepth 1 -type f | wc -l) $1"' _ {} \; 2>/dev/null \
  | sort -rn | head -20

Lệnh này đếm số file trực tiếp bên trong mỗi thư mục con của /var, giúp bạn phát hiện nhanh thư mục nào đang phình to bất thường mà không cần duyệt toàn bộ filesystem.

Xử lý theo từng nguyên nhân

Mỗi nguồn gây full inode có đặc điểm nhận dạng và cách dọn riêng. Xóa sai thư mục có thể làm hỏng ứng dụng, nên bạn cần xác định đúng nguyên nhân trước khi chạy lệnh xóa.

1. File session PHP tích tụ trong /var/lib/php/sessions

Đây là nguyên nhân phổ biến nhất trên các server chạy PHP-FPM. Mỗi phiên truy cập tạo một file sess_* trong /var/lib/php/sessions (Ubuntu/Debian) hoặc /var/lib/php/session (CentOS/RHEL). Khi garbage collector của PHP không chạy đúng cách hoặc session.gc_probability bị đặt về 0, hàng trăm nghìn file session cũ sẽ tích tụ và đốt sạch inode.

Kiểm tra số lượng file session hiện tại:

find /var/lib/php/sessions -type f | wc -l

Xóa an toàn các file session cũ hơn 2 ngày, giữ lại session đang hoạt động trong 48 giờ gần nhất:

find /var/lib/php/sessions -type f -name 'sess_*' -mtime +2 -delete

Nếu thư mục chứa hàng triệu file và lệnh rm * báo lỗi Argument list too long, cách trên vẫn hoạt động vì find -delete xử lý từng file tuần tự, không bị giới hạn bởi shell argument list.

2. File cache WordPress phình to trong wp-content/cache

Các plugin cache như W3 Total Cache, LiteSpeed Cache hay WP Rocket tạo ra hàng trăm nghìn file nhỏ trong wp-content/cache, wp-content/cache/object và wp-content/cache/page_enhanced. Cơ chế page cache lưu từng phiên bản HTML theo URL, kết hợp object cache lưu từng key riêng lẻ. Số file tăng theo cấp số nhân nếu không có giới hạn dung lượng cache.

Kiểm tra dung lượng inode của thư mục cache:

du --inodes -sh /home/*/public_html/wp-content/cache/ 2>/dev/null
find /home/*/public_html/wp-content/cache/ -type f 2>/dev/null | wc -l

Xóa toàn bộ cache cũ hơn 7 ngày:

find /home/*/public_html/wp-content/cache/ -type f -mtime +7 -delete

Nếu muốn xóa sạch và để plugin tái tạo cache mới, dùng:

rm -rf /home/*/public_html/wp-content/cache/*

Sau khi xóa cache, truy cập lại website để plugin tái tạo cache. Lưu ý rằng một số plugin có cài đặt giới hạn số file cache tối đa. Bạn nên bật tùy chọn đó nếu có.

3. Mail queue bị kẹt trong /var/spool/postfix

Postfix tạo một file riêng cho mỗi email trong queue. Khi có sự cố gửi mail, ví dụ script bị lỗi gửi hàng nghìn email thông báo hoặc server bị lợi dụng để spam, deferred queue có thể tích tụ hàng trăm nghìn file nhỏ. Phân vùng chứa /var/spool/postfix sẽ hết inode trước khi hết dung lượng byte.

Kiểm tra số lượng file trong từng queue:

for d in maildrop incoming active deferred bounce defer hold corrupt; do
  count=$(find /var/spool/postfix/$d -type f 2>/dev/null | wc -l)
  echo "$d: $count files"
done

Xóa các file trong deferred queue cũ hơn 3 ngày. Cách này an toàn cho hầu hết trường hợp, vì mail cũ thường không còn giá trị gửi lại:

find /var/spool/postfix/deferred -type f -mtime +3 -delete

Nếu muốn xóa sạch toàn bộ queue để giải phóng inode ngay lập tức và chấp nhận mất các email đang chờ, dùng:

postsuper -d ALL deferred

Sau khi dọn queue, kiểm tra lại bằng mailq để xác nhận số lượng email đã giảm.

4. Log hệ thống trong /var/log không được xoay vòng

Khi logrotate bị lỗi cấu hình hoặc không chạy, các file log như syslog, auth.log, messages có thể phình to. Nghiêm trọng hơn, systemd journal trong /var/log/journal lưu từng entry dưới dạng file riêng, và hàng triệu file journal nhỏ sẽ đốt sạch inode nhanh chóng.

Kiểm tra dung lượng và số file trong /var/log:

du --inodes -sh /var/log/*
journalctl --disk-usage

Giới hạn journal systemd chỉ giữ log trong 7 ngày gần nhất và tối đa 500 MB:

journalctl --vacuum-time=7d
journalctl --vacuum-size=500M

Lệnh journalctl --vacuum-size chỉ xóa các file journal đã archive, không ảnh hưởng đến journal đang hoạt động, nên an toàn để chạy trên server production.

Xóa các file log cũ hơn 30 ngày trong /var/log, trừ các file đang được ghi:

find /var/log -type f \( -name "*.log.*" -o -name "*.gz" -o -name "*.old" \) -mtime +30 -delete

Sau khi dọn log, bạn nên thiết lập cấu hình Logrotate để tự động xoay vòng log nhằm ngăn vấn đề tái diễn.

5. File tạm trong /tmp và systemd-private

Thư mục /tmp và các thư mục con /tmp/systemd-private-* chứa file tạm từ các dịch vụ hệ thống. Một số ứng dụng không tự dọn file tạm, dẫn đến tích tụ hàng trăm nghìn file rác theo thời gian. Trên các server chạy nhiều phiên bản PHP khác nhau, mỗi phiên bản có thể ghi session vào một thư mục /tmp/systemd-private-*/tmp/ riêng.

Liệt kê các file tạm cũ hơn 3 ngày:

find /tmp -type f -mtime +3 2>/dev/null | wc -l

Xóa file tạm cũ hơn 3 ngày trong /tmp, không xóa thư mục systemd-private để tránh ảnh hưởng dịch vụ đang chạy:

find /tmp -maxdepth 1 -type f -mtime +3 -delete

Dọn file session trong các thư mục systemd-private:

find /tmp/systemd-private-*/tmp/ -type f -name 'sess_*' -mtime +2 -delete 2>/dev/null

Nguồn gây đầy inode và cách xử lý

Nguồn gây ra	Thư mục thường gặp	Lệnh kiểm tra nhanh	Cách xử lý
PHP session	/var/lib/php/sessions	find /var/lib/php/sessions -type f | wc -l	find ... -mtime +2 -delete + tăng session.gc_probability
WordPress cache	wp-content/cache/	du --inodes -sh wp-content/cache/	find ... -mtime +7 -delete + giới hạn cache trong plugin
Mail queue	/var/spool/postfix/deferred	find /var/spool/postfix/deferred -type f | wc -l	postsuper -d ALL deferred hoặc xóa file cũ hơn 3 ngày
Log hệ thống	/var/log, /var/log/journal	journalctl --disk-usage	journalctl --vacuum-size=500M + logrotate
File tạm	/tmp, /tmp/systemd-private-*/tmp/	find /tmp -type f -mtime +3 | wc -l	find /tmp -maxdepth 1 -type f -mtime +3 -delete

Xử lý trên control panel phổ biến

Mỗi control panel có đường dẫn session và cơ chế quản lý inode riêng. Dưới đây là cách làm với CyberPanel, DirectAdmin và cPanel, ba panel phổ biến nhất trên VPS Việt Nam.

CyberPanel: session nằm trong /var/lib/lsphp/session

CyberPanel dùng LiteSpeed PHP (lsphp) thay vì PHP-FPM tiêu chuẩn, nên session được lưu trong /var/lib/lsphp/session/. Đây là nguyên nhân full inode phổ biến nhất trên CyberPanel nếu garbage collector không chạy đúng.

Kiểm tra số lượng file session:

find /var/lib/lsphp/session/ -type f -name 'sess_*' | wc -l

Xóa file session cũ hơn 2 ngày:

find /var/lib/lsphp/session/ -type f -name 'sess_*' -mtime +2 -delete

Sau khi dọn, kiểm tra lại inode và khởi động lại lsphp nếu cần:

df -i
systemctl restart lsws

DirectAdmin: kiểm tra qua dashboard và SSH

DirectAdmin hiển thị mức sử dụng inode theo từng user account trên dashboard chính (Admin Level → Show All Users). Trên shared hosting, giới hạn inode thường được đặt theo gói hosting, và user vượt ngưỡng sẽ không tạo được file mới.

Kiểm tra inode toàn server qua SSH:

df -i

Tìm user hoặc thư mục chiếm nhiều inode nhất trong /home:

for user in /home/*; do
  echo -n "$(basename $user): "
  find "$user" -xdev -type f 2>/dev/null | wc -l
done | sort -t: -k2 -rn | head -10

DirectAdmin thường gặp full inode do Message System ticket và backup cũ tích tụ trong thư mục user. Dọn ticket cũ:

find /usr/local/directadmin/data/tickets -type f -mtime +30 -delete 2>/dev/null

Dọn backup cũ trong /home/admin/admin_backups nếu có:

find /home/admin/admin_backups -name '*.tar.gz' -mtime +7 -delete 2>/dev/null

cPanel: kiểm tra File Usage và dọn qua SSH

cPanel hiển thị số inode đang dùng so với giới hạn trong mục Statistics → File Usage trên trang chủ tài khoản. Nếu con số này chạm trần trong khi Disk Usage vẫn thấp, bạn đang bị full inode do tài khoản, không phải do toàn server.

Kiểm tra inode toàn server:

df -i

cPanel dùng MultiPHP và session có thể nằm ở nhiều vị trí khác nhau tùy phiên bản PHP. Kiểm tra tất cả thư mục session có thể có:

ls -d /var/cpanel/php/sessions/*/ 2>/dev/null
ls -d /tmp/systemd-private-*/tmp/ 2>/dev/null

Xóa session cũ trong từng thư mục tương ứng. Thay ea-php81 bằng phiên bản PHP thực tế đang dùng:

find /var/cpanel/php/sessions/ea-php81/ -type f -name 'sess_*' -mtime +2 -delete 2>/dev/null

Nếu server dùng CloudLinux với giới hạn inode theo package, bạn cần điều chỉnh giới hạn trong WHM → Packages → Feature Manager hoặc tăng giới hạn trong gói tương ứng.

Phòng ngừa inode bị đầy trở lại

Dọn inode chỉ giải quyết triệu chứng. Để không phải xử lý tình trạng full inode lặp lại mỗi vài tuần, bạn cần thiết lập cơ chế tự động dọn dẹp và giám sát định kỳ.

Cấu hình logrotate cho /var/log

Logrotate là công cụ tiêu chuẩn trên hầu hết bản phân phối Linux, chạy hàng ngày qua cron để xoay vòng, nén và xóa log cũ theo cấu hình trong /etc/logrotate.conf và /etc/logrotate.d/. Kiểm tra logrotate có đang chạy đúng không:

systemctl status logrotate.timer
cat /etc/logrotate.conf | grep -E 'rotate|weekly|daily'

Một cấu hình logrotate điển hình cho syslog và auth.log giới hạn 4 bản archive và nén lại để tiết kiệm inode:

/var/log/syslog {
    rotate 4
    weekly
    missingok
    notifempty
    compress
    delaycompress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Chi tiết đầy đủ về cấu hình logrotate cho từng loại log trên VPS bạn xem trong bài cấu hình Logrotate để tự động xoay vòng log.

Cronjob tự động dọn PHP session

Thay vì chờ garbage collector của PHP chạy ngẫu nhiên theo tỉ lệ gc_probability/gc_divisor, bạn nên tạo cronjob dọn session cũ mỗi ngày. Điều này đặc biệt quan trọng trên server có lưu lượng truy cập cao, nơi GC mặc định có thể không đủ nhanh để theo kịp tốc độ tạo session mới.

Mở crontab của root:

crontab -e

Thêm dòng sau để dọn session cũ hơn 1 ngày vào 3 giờ sáng mỗi ngày. Điều chỉnh đường dẫn cho phù hợp với PHP-FPM hoặc lsphp:

0 3 * * * find /var/lib/php/sessions -type f -name 'sess_*' -mtime +1 -delete 2>/dev/null

Hướng dẫn chi tiết cách viết cronjob, cú pháp thời gian và các tùy chọn nâng cao có trong bài thiết lập cron job tự động dọn dẹp file.

Điều chỉnh session.gc_maxlifetime và session.gc_probability trong php.ini

Hai tham số quyết định tốc độ dọn session tự động của PHP:

• session.gc_maxlifetime = 1440: session được coi là rác sau 1440 giây (24 phút). Với website có người dùng đăng nhập lâu, bạn có thể tăng lên 3600 hoặc 7200 để tránh đăng xuất quá sớm, nhưng đừng để quá cao vì session cũ sẽ tích tụ lâu hơn.
• session.gc_probability = 1 và session.gc_divisor = 1000: mỗi request có 0.1% cơ hội kích hoạt garbage collector. Nếu gc_probability = 0, GC không bao giờ chạy tự động và session sẽ tích tụ vô hạn.

Tìm file php.ini đang được PHP-FPM sử dụng và kiểm tra giá trị hiện tại:

php -i | grep -E 'session.gc_maxlifetime|session.gc_probability|Loaded Configuration File'

Chỉnh sửa trực tiếp trong file php.ini. Đường dẫn có thể khác nhau tùy phiên bản PHP:

sed -i 's/^session.gc_probability = 0/session.gc_probability = 1/' /etc/php/*/fpm/php.ini
systemctl restart php*-fpm

Giám sát inode định kỳ và bảo mật server

Thiết lập cronjob kiểm tra inode mỗi giờ và gửi cảnh báo khi vượt ngưỡng 85%. Script đơn giản dùng df -i và awk:

#!/bin/bash
THRESHOLD=85
df -i --output=pcent / | tail -1 | tr -d '%' | while read pct; do
  if [ "$pct" -ge "$THRESHOLD" ]; then
    echo "CANH BAO: Inode tren / da dat ${pct}%" | mail -s "Inode Alert" [email protected]
  fi
done

Lưu script vào /usr/local/bin/check-inode.sh, cấp quyền thực thi bằng chmod +x, và thêm vào crontab chạy mỗi giờ:

0 * * * * /usr/local/bin/check-inode.sh

Song song với giám sát, bạn nên rà soát các biện pháp bảo mật tổng thể để ngăn kẻ tấn công lợi dụng form mail hoặc upload file để làm đầy inode. Các bước như giới hạn tỉ lệ request, cấu hình firewall và tắt các dịch vụ không cần thiết được tổng hợp trong bài các bước bảo mật VPS Linux.

Một số lỗi bất thường sau khi dọn inode

1. Đã xóa file nhưng df -i vẫn báo 100%

Triệu chứng: Bạn đã xóa hàng loạt file session hoặc log, nhưng df -i vẫn hiển thị IUse% 100%. Dung lượng không được giải phóng dù ls không còn thấy file.

Nguyên nhân: Một tiến trình vẫn đang giữ file descriptor mở trên file đã bị xóa. Trong Linux, khi bạn rm một file, directory entry bị xóa nhưng inode và data block chỉ được giải phóng khi tất cả tiến trình đóng file descriptor. Nếu PHP-FPM, Postfix hoặc rsyslog vẫn đang giữ file, inode không được trả về filesystem.

Kiểm tra: Liệt kê các file đã bị xóa nhưng vẫn được tiến trình giữ mở:

lsof +L1 2>/dev/null | grep -i deleted
lsof | grep deleted | head -20

Cách xử lý: Restart dịch vụ đang giữ file. Thay php8.1-fpm bằng tên dịch vụ thực tế:

systemctl restart php8.1-fpm
systemctl restart postfix

Sau khi restart, chạy lại df -i để xác nhận inode đã được giải phóng. Nếu không thể restart dịch vụ ngay, ví dụ đang trong giờ cao điểm, bạn có thể dùng kill -HUP để tiến trình đóng file descriptor mà không ngắt kết nối hoàn toàn.

2. rm báo lỗi “Argument list too long”

Triệu chứng: Bạn chạy rm * hoặc rm -rf * trong thư mục chứa hàng trăm nghìn file và nhận lỗi -bash: /bin/rm: Argument list too long. Shell không thể mở rộng wildcard thành danh sách đối số đủ lớn để truyền cho rm.

Nguyên nhân: Giới hạn ARG_MAX của kernel, thường khoảng 2 MB trên Linux, khiến shell không thể truyền hàng trăm nghìn tên file cùng lúc cho một lệnh duy nhất.

Cách xử lý: Dùng find -delete thay vì rm wildcard. Lệnh này xử lý từng file tuần tự, không bị giới hạn argument list:

find /var/lib/php/sessions -type f -name 'sess_*' -delete

Nếu muốn theo dõi tiến độ xóa, bạn có thể pipe qua pv nếu đã cài, hoặc đếm số file còn lại trước và sau:

find /var/lib/php/sessions -type f -name 'sess_*' | wc -l

Phương án thay thế khi cần xóa nhanh hơn: tạo một thư mục mới, di chuyển các file cần giữ sang đó, xóa cả thư mục cũ bằng rm -rf, rồi đổi tên thư mục mới về tên cũ. Cách này nhanh hơn nhưng cần cẩn thận để không mất dữ liệu quan trọng.

3. Dịch vụ vẫn lỗi sau khi đã dọn inode

Triệu chứng: df -i đã về mức bình thường dưới 50%, nhưng website vẫn trả lỗi 500, PHP-FPM không khởi động hoặc database không kết nối được.

Nguyên nhân: Khi inode đầy, nhiều dịch vụ ghi log hoặc ghi file trạng thái thất bại và có thể đã crash hoặc rơi vào trạng thái không ổn định. PHP-FPM có thể đã dừng worker pool, MySQL/MariaDB có thể không mở được file tạm, hoặc web server không ghi được access log.

Kiểm tra: Kiểm tra trạng thái các dịch vụ chính:

systemctl status nginx php8.1-fpm mariadb
journalctl -xe --since "10 minutes ago" | grep -i "no space\|error\|failed"

Cách xử lý: Restart tuần tự các dịch vụ liên quan:

systemctl restart php8.1-fpm
systemctl restart nginx
systemctl restart mariadb

Kiểm tra lại log ứng dụng để xác nhận không còn lỗi ghi file. Nếu dịch vụ vẫn không khởi động sau khi restart, kiểm tra cấu hình của dịch vụ đó có tham chiếu đến đường dẫn file không tồn tại hoặc quyền truy cập sai.

Trường hợp hệ thống bị hỏng nặng, filesystem có lỗi sau khi hết inode đột ngột, hoặc bạn không thể khôi phục dịch vụ sau nhiều lần restart, giải pháp cuối cùng là cài lại hệ điều hành VPS từ snapshot hoặc backup gần nhất. Trước khi thực hiện, hãy đảm bảo bạn đã sao lưu toàn bộ dữ liệu quan trọng.

Sau khi khắc phục xong sự cố, đây là thời điểm phù hợp để rà soát lại cấu hình bảo mật. Nếu server chưa có firewall, bạn nên cấu hình UFW firewall để giới hạn cổng truy cập và giảm bề mặt tấn công, đặc biệt quan trọng nếu sự cố full inode có nguyên nhân từ hoạt động bất thường bên ngoài.

Nội dung mang tính tham khảo. Lệnh, cú pháp, đường dẫn file và tùy chọn cấu hình có thể thay đổi theo phiên bản hệ điều hành, phiên bản phần mềm và môi trường cụ thể. Nên kiểm thử, sao lưu dữ liệu và đánh giá rủi ro trước khi áp dụng lên server production.