umount: thiết bị đang bận. Tại sao?

Khi chạy umount /pathtôi nhận được:

umount: /path: device is busy.

Hệ thống tập tin rất lớn, vì vậy lsof +D /pathkhông phải là một lựa chọn thực tế.

lsof /path, lsof +f -- /pathvà fuser /pathtất cả không trả lại gì cả. fuser -v /pathcho:

                  USER        PID ACCESS COMMAND
/path:            root     kernel mount /path

đó là bình thường cho tất cả các hệ thống tập tin gắn kết không sử dụng.

umount -lvà umount -fkhông đủ tốt cho tình huống của tôi.

Làm thế nào để tôi tìm ra lý do tại sao kernel nghĩ rằng hệ thống tập tin này là bận rộn?

Có vẻ như nguyên nhân cho vấn đề của tôi là do nfs-kernel-serverxuất thư mục. Có nfs-kernel-serverlẽ đi đằng sau các tệp mở bình thường và do đó không được liệt kê bởi lsofvà fuser.

Khi tôi dừng thư mục nfs-kernel-servertôi có thể umount.

Tôi đã tạo một trang với các ví dụ về tất cả các giải pháp cho đến nay: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

Để thêm vào nhận xét của BruceCran ở trên, nguyên nhân cho biểu hiện của tôi về vấn đề này vừa nãy là do một vòng lặp ngược cũ . Tôi đã kiểm tra đầu ra của / , và , kiểm tra xem một số máy chủ nfs-kernel cũ có đang chạy hay không, đã tắt hạn ngạch, đã cố gắng (nhưng không thành công) và đã từ bỏ bản thân để từ bỏ thời gian hoạt động 924 ngày trước khi cuối cùng kiểm tra đầu ra của và tìm hai cũ loopbacks cấu hình-nhưng-không-gắn kết:fuser -vm <mountpoint>lsof +D <mountpoint>mountcat /proc/mountsumount -f <mountpoint>losetup

parsley:/mnt# cat /proc/mounts 
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0

sau đó

parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy

parsley:/mnt# losetup -a    
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)

parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#

Một bài đăng trên diễn đàn Gentoo cũng liệt kê các tệp hoán đổi là thủ phạm tiềm năng; mặc dù việc hoán đổi các tập tin có lẽ khá hiếm ngày nay, nhưng không thể kiểm tra đầu ra của nó cat /proc/swaps. Tôi không chắc liệu hạn ngạch có thể ngăn chặn được một cuộc chiến không - tôi đang nắm chặt ống hút.

Thay vì sử dụng lsof để thu thập dữ liệu thông qua hệ thống tệp, chỉ cần sử dụng tổng danh sách các tệp đang mở và grep nó. Tôi thấy lợi nhuận này phải nhanh hơn, mặc dù nó kém chính xác hơn. Nó sẽ hoàn thành công việc.

lsof | grep '/path'

Đối với tôi, quá trình vi phạm là một daemon chạy trong một cái chroot. Bởi vì nó ở trong một cái chroot, lsofvà fusersẽ không tìm thấy nó.

Nếu bạn nghi ngờ mình có thứ gì đó còn sót lại trong chroot, sudo ls -l /proc/*/root | grep chrootsẽ tìm ra thủ phạm (thay thế "chroot" bằng đường dẫn đến chroot).

Mở tập tin

Các quy trình với các tệp đang mở là thủ phạm thông thường. Hiển thị chúng:

lsof +f -- <mountpoint or device>

Có một lợi thế cho việc sử dụng /dev/<device>hơn là /mountpoint: một điểm gắn kết sẽ biến mất sau một umount -lhoặc có thể bị ẩn bởi một giá treo.

fusercũng có thể được sử dụng, nhưng theo tôi thì lsofcó một đầu ra hữu ích hơn. Tuy nhiên fuserrất hữu ích khi nói đến việc tiêu diệt các quá trình gây ra các bộ phim truyền hình của bạn để bạn có thể tiếp tục cuộc sống của mình.

Liệt kê các tập tin trên <mountpoint>(xem cảnh báo ở trên):

fuser -vmM <mountpoint>

Chỉ giết tương tác các quá trình với các tệp được mở để ghi:

fuser -vmMkiw <mountpoint>

Sau khi đếm lại chỉ đọc ( mount -o remount,ro <mountpoint>), an toàn (r) để giết tất cả các quy trình còn lại:

fuser -vmMk <mountpoint>

Đỉnh núi

Thủ phạm có thể là chính hạt nhân. Một hệ thống tập tin khác được gắn trên hệ thống tập tin mà bạn đang cố gắng umountsẽ gây ra đau buồn. Kiểm tra với:

mount | grep <mountpoint>/

Đối với mount loopback, cũng kiểm tra đầu ra của:

losetup -la

Inodes nặc danh (Linux)

Các nút ẩn danh có thể được tạo bởi:

• Tệp tạm thời ( opencó O_TMPFILE)
• đồng hồ inotify
• [sự kiện]
• [sự kiện]
• [hẹn giờ]

Đây là những loại khó nắm bắt nhất của pokemon, và xuất hiện trong lsof's TYPEcột như a_inode(được cung cấp tài liệu trong lsoftrang người đàn ông ).

Chúng sẽ không xuất hiện lsof +f -- /dev/<device>, vì vậy bạn sẽ cần:

lsof | grep a_inode

Để tiêu diệt các quá trình giữ các nút ẩn danh, hãy xem: Liệt kê các đồng hồ inotify hiện tại (tên đường dẫn, PID) .

Để bộ nhiệt áp báo cáo về các PID đang mở ngàm, bạn phải sử dụng -m

fuser -m /path

Chúng tôi có một hệ thống độc quyền trong đó hệ thống tập tin gốc thường chỉ đọc. Đôi khi, khi các tập tin phải được sao chép, nó được ghi lại đọc-ghi:

mount -oremount,rw /

Và sau đó kể lại:

mount -oremount,ro /

Lần này, mounttiếp tục đưa ra mount: / is busylỗi. Nó được gây ra bởi một quá trình giữ một mô tả mở cho một tệp đã được thay thế bằng một số lệnh, được thực thi khi hệ thống tệp được đọc-ghi. Dòng quan trọng từ lsof -- /đầu ra xảy ra là (tên đã được thay đổi):

replicate  1719 admin DEL REG 8,5  204394 /opt/gns/lib/replicate/modules/md_es.so

Lưu ý DELtrong đầu ra. Chỉ cần khởi động lại quá trình giữ tập tin đã xóa đã giải quyết vấn đề.

lsofvà fusercũng không cho tôi bất cứ thứ gì.

Sau một quá trình đổi tên tất cả các thư mục có thể thành .old và khởi động lại hệ thống mỗi lần sau khi tôi thực hiện các thay đổi, tôi tìm thấy một thư mục cụ thể (liên quan đến hậu tố) chịu trách nhiệm.

Hóa ra là tôi đã từng làm một liên kết tượng trưng từ /var/spool/postfixđể /disk2/pers/mail/postfix/varspoolnhằm giảm thiểu đĩa ghi trên một hệ thống tập tin gốc sdcard-based (Sheeva cắm).

Với liên kết tượng trưng này, ngay cả sau khi dừng postfixvà dovecotcác dịch vụ (cả ps auxcũng như netstat -tuanpkhông hiển thị bất cứ điều gì liên quan) tôi đã không thể unmount /disk2/pers.

Khi tôi gỡ bỏ symlink và cập nhật các tập tin postfixvà dovecotcấu hình để trỏ trực tiếp đến các thư mục mới trên /disk2/pers/tôi đã có thể dừng thành công các dịch vụ và unmountthư mục.

Lần tới tôi sẽ xem xét kỹ hơn về đầu ra của:

ls -lR /var | grep ^l | grep disk2

Lệnh trên sẽ liệt kê đệ quy tất cả các liên kết tượng trưng trong cây thư mục (bắt đầu từ đây /var) và lọc ra các tên đó trỏ đến một điểm gắn kết đích cụ thể (ở đây là đĩa2).

Tôi đã có vấn đề này và hóa ra có những phiên màn hình hoạt động trong nền mà tôi không biết. Tôi đã kết nối với phiên màn hình hoạt động khác và vỏ của nó thậm chí không ngồi trong thư mục được gắn. Giết chết các phiên shell khác đã khắc phục vấn đề cho tôi.

Chỉ cần nghĩ rằng tôi sẽ chia sẻ giải pháp của tôi.

Hôm nay vấn đề là một ổ cắm mở (cụ thể tmux):

mount /mnt/disk
export TMPDIR=/mnt/disk
tmux
<<detatch>>
umount /mnt/disk
umount: /mnt/disk: device is busy.
lsof | grep /mnt/disk
tmux      20885             root    6u     unix 0xffff880022346300        0t0    3215201 /mnt/disk/tmux-0/default

Tôi có một vài bindvà overlaygắn kết dưới giá treo của tôi đang chặn tôi, kiểm tra hoàn thành tab cho điểm gắn kết bạn muốn ngắt kết nối. Tôi nghi ngờ đó là đặc biệt của lớp phủ nhưng cũng có thể là các liên kết

Đây là một cách giải quyết hơn là một câu trả lời, nhưng tôi sẽ đăng nó trong trường hợp nó có thể giúp được ai đó.

Trong trường hợp của tôi, tôi đã cố gắng sửa đổi LVM vì tôi muốn làm cho phân vùng / var lớn hơn, vì vậy tôi cần phải vượt qua nó. Tôi đã thử tất cả các nhận xét và trả lời trong bài đăng này (cảm ơn tất cả mọi người và đặc biệt là @ ole-tange vì đã thu thập chúng) và vẫn nhận được lỗi "thiết bị đang bận".

Tôi cũng đã cố gắng giết hầu hết các quy trình theo thứ tự được chỉ định trong 0 runlevel, chỉ trong trường hợp thứ tự có liên quan trong trường hợp của tôi, nhưng điều đó cũng không giúp được gì. Vì vậy, những gì tôi đã làm là tạo cho tôi một runlevel tùy chỉnh (kết hợp đầu ra của chkconfig thành các lệnh chkconfig --level mới) sẽ rất giống với 1 (chế độ người dùng đơn) nhưng với khả năng mạng (với mạng ssh và xinet).

Khi tôi đang sử dụng redhat, runlevel 4 được đánh dấu là "không sử dụng / người dùng xác định", vì vậy tôi đã sử dụng cái đó và chạy init 4 Trong trường hợp của tôi, điều này là ổn vì tôi cần khởi động lại máy chủ trong mọi trường hợp, nhưng có lẽ đó là trường hợp của bất cứ ai điều chỉnh các đĩa.