Từ triết lý “Everything is a file” đến những rắc rối thực tế trên Server
Dân Linux chắc chẳng lạ gì câu thần chú: “Everything is a file”. Từ file văn bản, thư mục cho đến card mạng hay socket – tất cả đều được kernel quản lý qua File Descriptor (FD).
Thế nhưng, đời không như là mơ. Bạn sẽ sớm gặp cảnh server báo lỗi Too many open files, hoặc xóa file rồi mà ổ cứng vẫn báo đầy. Hồi làm hệ thống cho sàn TMĐT trên CentOS 7, mình từng “dính chưởng” app Java bị leak kết nối. Nó ngốn sạch 1024 FD mặc định chỉ trong 15 phút, làm cả hệ thống tê liệt. Lúc đó, lsof (LiSt Open Files) chính là cứu cánh để mình tóm đúng PID đang gây họa.
So sánh lsof với các công cụ kiểm tra hệ thống khác
Nhiều anh em mới vào nghề thường chỉ dùng netstat hay ss khi soi port. Tuy nhiên, mỗi món nghề lại có thế mạnh riêng mà bạn cần phân biệt rõ.
lsof vs netstat/ss
- netstat/ss: Chuyên thống kê mạng, cho biết port nào đang mở. Tuy nhiên, thông tin về tiến trình (PID) đi kèm đôi khi khá sơ sài.
- lsof: Soi socket dưới góc độ một file descriptor. Nó không chỉ chỉ mặt đặt tên port mà còn liệt kê được các thư viện
.somà tiến trình đó đang nạp vào RAM.
lsof vs fuser
- fuser: Dùng để “kill” nhanh các tiến trình đang truy cập vào một file cụ thể.
- lsof: Cung cấp cái nhìn chi tiết hơn về thuộc tính file như User, FD, Type, hay Device Size.
Điểm cộng của lsof là khả năng lọc cực mạnh theo user, port hoặc thư mục mount point. Điểm trừ? Nó khá tốn tài nguyên nếu hệ thống đang mở hàng triệu file cùng lúc do phải quét thư mục /proc của kernel.
Lỗi “Too Many Open Files”: Đừng coi thường cấu hình mặc định
Lỗi này xảy ra khi một tiến trình cố mở thêm file vượt quá giới hạn (limit) cho phép. Bạn cần phân biệt hai loại giới hạn:
- Soft Limit: Ngưỡng cảnh báo, người dùng có thể tự nới lỏng.
- Hard Limit: Trần nhà thực sự, chỉ quyền root mới có thể can thiệp.
Nguyên nhân thường do ứng dụng code lỗi (không đóng connection DB) hoặc do config mặc định của Linux quá thấp. Con số 1024 file mặc định là quá bèo bọt cho các web server hiện đại chạy Nginx hay Redis.
5 Tuyệt chiêu sử dụng lsof trong troubleshooting thực tế
Dưới đây là những lệnh “bỏ túi” mình hay dùng nhất trên môi trường production.
1. Truy tìm tiến trình chiếm Port cực nhanh
Khi khởi động Docker mà dính lỗi Address already in use, hãy dùng ngay combo này:
# Soi tiến trình đang chiếm port 80
sudo lsof -i :80
# Tìm các kết nối TCP đang ở trạng thái LISTEN
sudo lsof -nP -iTCP -sTCP:LISTENTrong đó, -n và -P giúp bỏ qua phân giải tên miền/port, giúp lệnh chạy nhanh tức thì.
2. Kiểm tra file một User đang mở
Hữu ích khi bạn nghi ngờ một tài khoản nào đó đang chạy script lén lút:
sudo lsof -u dev_user3. Tìm “File ma” – Xóa nhưng không mất dung lượng
Tình huống kinh điển: Bạn xóa file log nặng 50GB bằng lệnh rm, nhưng df -h vẫn báo ổ cứng đầy 100%. Lý do là một tiến trình vẫn đang giữ file đó.
# Tìm các file đã bị xóa nhưng vẫn còn FD
sudo lsof +L1Chỉ cần restart dịch vụ hoặc kill PID đó, dung lượng sẽ lập tức được trả lại.
4. Soi các file trong thư mục đang bị chiếm dụng
Khi bạn umount ổ cứng mà bị báo device is busy:
sudo lsof +D /data/storage5. Đếm số lượng FD theo từng tiến trình
Để tìm kẻ chủ mưu gây lỗi hệ thống, mình dùng câu lệnh tổng hợp này:
sudo lsof | awk '{print $1, $2}' | sort | uniq -c | sort -rn | head -n 10Kết quả sẽ liệt kê Top 10 tiến trình đang “ngốn” nhiều file nhất.
Xử lý triệt để lỗi Too Many Open Files
Khi đã bắt được bệnh, hãy tăng giới hạn hệ thống. Lưu ý: Đừng chỉ dùng ulimit vì nó sẽ mất tác dụng khi bạn tắt terminal.
Bước 1: Kiểm tra thực tế
# Check giới hạn của user hiện tại
ulimit -n
# Soi giới hạn của một PID cụ thể
cat /proc/[PID]/limits | grep "Max open files"Bước 2: Cấu hình vĩnh viễn
Sửa file /etc/security/limits.conf và thêm các dòng sau:
* soft nofile 65535
* hard nofile 65535
root soft nofile 65535
root hard nofile 65535Bước 3: Lưu ý cho Systemd
Trên Ubuntu 22.04 hay AlmaLinux, các service chạy qua Systemd thường phớt lờ limits.conf. Bạn phải can thiệp vào file service:
[Service]
...
LimitNOFILE=65535
...Sau đó, nhớ systemctl daemon-reload để thay đổi có hiệu lực.
Lời kết
Làm hệ thống không sợ lỗi, chỉ sợ không biết lỗi nằm ở đâu. lsof không chỉ là lệnh xem file, nó là công cụ để bạn hiểu cách kernel vận hành luồng dữ liệu. Trong quá trình tối ưu server, mình rút ra bài học: luôn phải giám sát chỉ số Open Files song song với CPU/RAM. Đừng đợi đến khi khách hàng than phiền mới đi tìm lệnh lsof.
