it-swarm-vi.com

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

Khi chạy umount /path Tôi có:

umount: /path: device is busy.

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

lsof /path, lsof +f -- /pathfuser /path tất cả không trả lại gì cả. fuser -v /path đưa ra:

                  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 -lumount -f khô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?

186
Ole Tange

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

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

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

149
Ole Tange

Để thêm vào BruceCran 's bình luận ở trên, nguyên nhân dẫn đến sự biểu hiện của tôi về vấn đề này là a stale mountback loopback. Tôi đã kiểm tra đầu ra của fuser -vm <mountpoint>/lsof +D <mountpoint>, mountcat /proc/mounts, đã 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, đã thử (nhưng không thành công) a umount -f <mountpoint> và tất cả trừ bỏ bản thân mình để 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 losetup và tìm hai vòng lặp cũ được cấu hình nhưng không được gắn kết:

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#

A 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 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 bám vào ống hút.

42
ZakW

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'
24
Caleb

Đố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 chroot, lsoffuser sẽ không tìm thấy nó.

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

23
cibyr

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ế khi sử dụng /dev/<device> chứ không phải /mountpoint: một điểm gắn kết sẽ biến mất sau một umount -l hoặc nó có thể bị ẩn bởi một giá treo.

fuser cũng có thể được sử dụng, nhưng theo tôi thì lsof có đầu ra hữu ích hơn. Tuy nhiên fuser rất hữu ích khi giết chế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 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 khác được gắn trên hệ thống tệp mà bạn đang cố gắng umount sẽ gây đau buồn. Kiểm tra với:

mount | grep <mountpoint>/

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

losetup -la

Inodes nặc danh (Linux)

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

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

Đây là loại pokemon khó nắm bắt nhất và xuất hiện trong cột lsof 's TYPE dưới dạng a_inode (không có giấy tờ trong lsof man page ).

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

lsof | grep a_inode

Để giế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) .

11
Tom Hale

Để 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
5
Patrick

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 đọc lại ghi:

mount -oremount,rw /

Và sau đó kể lại:

mount -oremount,ro /

Tuy nhiên, lần này, mount tiếp tục cho mount: / is busy lỗ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ởi 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 (tên đã được thay đổi):

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

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

5
pdp

lsoffuser cũ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 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 tôi đã từng tạo một liên kết tượng trưng từ /var/spool/postfix đến /disk2/pers/mail/postfix/varspool để giảm thiểu việc ghi đĩa trên hệ thống tập tin gốc dựa trên SDCARD (Sheeva Plug).

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

Khi tôi xóa symlink và cập nhật các tệp cấu hình postfixdovecot để 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à unmount thư mục.

Lần sau 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 (ở đây bắt đầu từ /var) và lọc ra những tên đó trỏ đến một điểm gắn kết mục tiêu cụ thể (ở đây đĩa2).

4
captcha

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à Shell của nó thậm chí không ngồi trong thư mục được gắn. Giết những 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.

3
colemanm

Tôi có một vài bindoverlay gắn kết dưới ngàm 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

1
ThorSummoner

Đâ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ẽ đó sẽ là trường hợp của bất kỳ ai điều chỉnh các đĩa.

1
Gabriel Xunqueira

Hôm nay, vấn đề là một ổ cắm mở (cụ thể là 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
1
Ole Tange