it-swarm-id.com

umount: perangkat sedang sibuk. Mengapa?

Saat menjalankan umount /path Saya mendapat:

umount: /path: device is busy.

Sistem file sangat besar, jadi lsof +D /path bukan pilihan realistis.

lsof /path, lsof +f -- /path, dan fuser /path semua tidak menghasilkan apa-apa. fuser -v /path memberikan:

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

yang normal untuk semua sistem file yang dipasang tidak digunakan.

umount -l dan umount -f tidak cukup baik untuk situasi saya.

Bagaimana saya mencari tahu mengapa kernel berpikir sistem file ini sibuk?

186
Ole Tange

Sepertinya penyebab masalah saya adalah nfs-kernel-server sedang mengekspor direktori. nfs-kernel-server mungkin berada di belakang file terbuka normal dan karenanya tidak terdaftar oleh lsof dan fuser.

Ketika saya menghentikan nfs-kernel-server Saya bisa umount direktori.

Saya telah membuat halaman dengan contoh-contoh semua solusi sejauh ini di sini: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

149
Ole Tange

Untuk menambahkan BruceCrankomentar di atas, penyebab manifestasi saya dari masalah ini sekarang adalah basi mount loopback. Saya sudah memeriksa output fuser -vm <mountpoint>/lsof +D <mountpoint>, mount dan cat /proc/mounts, memeriksa apakah beberapa nfs-kernel-server lama berjalan, mematikan kuota, mencoba (tetapi gagal) a umount -f <mountpoint> dan semuanya mengundurkan diri untuk mengabaikan uptime 924 hari sebelum akhirnya memeriksa output losetup dan menemukan dua loopback dikonfigurasi-tapi-tidak-dipasang basi:

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

kemudian

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 posting forum Gentoo juga mencantumkan swapfile sebagai penyebab potensial; meskipun bertukar ke file mungkin sangat jarang hari ini, tidak ada salahnya untuk memeriksa output dari cat /proc/swaps. Saya tidak yakin apakah kuota dapat mencegah unmount - saya mencengkeram sedotan.

42
ZakW

Alih-alih menggunakan lsof untuk menjelajah melalui sistem file, cukup gunakan daftar total file yang terbuka dan ambil itu. Saya menemukan pengembalian ini harus lebih cepat, meskipun kurang akurat. Seharusnya menyelesaikan pekerjaan.

lsof | grep '/path'
24
Caleb

Bagi saya, proses menyinggung adalah daemon yang berjalan di chroot. Karena itu berada di chroot, lsof dan fuser tidak akan menemukannya.

Jika Anda curiga ada sesuatu yang tersisa berjalan di chroot, Sudo ls -l /proc/*/root | grep chroot akan menemukan pelakunya (ganti "chroot" dengan path ke chroot).

23
cibyr

Buka file

Proses dengan file terbuka adalah biang keladinya. Perlihatkan mereka:

lsof +f -- <mountpoint or device>

Ada keuntungan menggunakan /dev/<device> daripada /mountpoint: titik mount akan hilang setelah umount -l, atau mungkin disembunyikan oleh mount overlay.

fuser juga dapat digunakan, tetapi menurut saya lsof memiliki output yang lebih berguna. Namun fuser berguna untuk membunuh proses yang menyebabkan drama Anda sehingga Anda dapat melanjutkan hidup Anda.

Daftar file di <mountpoint> (lihat peringatan di atas):

fuser -vmM <mountpoint>

Hanya membunuh proses secara interaktif dengan file yang terbuka untuk ditulis:

fuser -vmMkiw <mountpoint>

Setelah remounting read-only (mount -o remount,ro <mountpoint>), aman untuk membunuh semua proses yang tersisa:

fuser -vmMk <mountpoint>

Mountpoints

Pelakunya bisa menjadi kernel itu sendiri. Filesystem lain yang terpasang pada filesystem yang Anda coba umount akan menyebabkan kesedihan. Periksa dengan:

mount | grep <mountpoint>/

Untuk pemasangan loopback, periksa juga output dari:

losetup -la

Inode anonim (Linux)

Anonim inode dapat dibuat oleh:

  • File sementara (open dengan O_TMPFILE)
  • inotify jam tangan
  • [eventfd]
  • [eventpoll]
  • [timerfd]

Ini adalah jenis pokemon yang paling sulit dipahami, dan muncul di lsof 's TYPE kolom sebagai a_inode (yang tidak berdokumen di halaman manual lsof ).

Mereka tidak akan muncul di lsof +f -- /dev/<device>, jadi Anda harus:

lsof | grep a_inode

Untuk membunuh proses yang memegang inode anonim, lihat: Sebutkan jam tangan yang tidak sah saat ini (pathname, PID) .

11
Tom Hale

Agar fuser melaporkan PID yang memegang mount terbuka, Anda harus menggunakan -m

fuser -m /path
5
Patrick

Kami memiliki sistem berpemilik di mana sistem file root biasanya hanya-baca. Kadang-kadang, ketika file harus disalin, itu dibuat ulang baca-tulis:

mount -oremount,rw /

Dan kemudian dipasang kembali:

mount -oremount,ro /

Namun kali ini, mount terus memberikan mount: / is busy kesalahan. Itu disebabkan oleh proses memegang deskriptor terbuka ke file yang telah diganti oleh beberapa perintah, yang dieksekusi ketika sistem file itu baca-tulis. Baris penting dari lsof -- / output terjadi (nama telah diubah):

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

Perhatikan DEL dalam output. Cukup memulai kembali proses memegang file yang dihapus untuk menyelesaikan masalah.

5
pdp

lsof dan fuser juga tidak memberi saya apa-apa.

Setelah proses penggantian nama semua direktori yang mungkin untuk .old dan me-reboot sistem setiap kali setelah saya membuat perubahan, saya menemukan satu direktori tertentu (berkaitan dengan postfix) yang bertanggung jawab.

Ternyata saya pernah membuat symlink dari /var/spool/postfix hingga /disk2/pers/mail/postfix/varspool untuk meminimalkan penulisan disk pada sistem file root berbasis SDCARD (Sheeva Plug).

Dengan symlink ini, bahkan setelah menghentikan layanan postfix dan dovecot (keduanya ps aux sebaik netstat -tuanp tidak menunjukkan apa pun yang terkait) Saya tidak dapat unmount /disk2/pers.

Ketika saya menghapus symlink dan memperbarui file konfigurasi postfix dan dovecot untuk menunjuk langsung ke direktori baru di /disk2/pers/ Saya berhasil menghentikan layanan dan unmount direktori.

Lain kali saya akan melihat lebih dekat pada output dari:

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

Perintah di atas secara rekursif akan mencantumkan semua tautan simbolik dalam pohon direktori (di sini mulai dari /var) dan memfilter nama-nama yang mengarah ke titik mount target tertentu (di sini disk2).

4
captcha

Saya mengalami masalah ini, dan ternyata ada sesi layar aktif di latar belakang yang tidak saya ketahui. Saya terhubung ke sesi layar aktif lainnya dan Shell-nya bahkan tidak sedang duduk di direktori yang di-mount. Membunuh sesi-sesi Shell lainnya memperbaiki masalah bagi saya.

Hanya berpikir saya akan membagikan resolusi saya.

3
colemanm

Saya memiliki beberapa mount bind dan overlay di bawah mount saya yang memblokir saya, periksa tab completion untuk titik mount yang ingin Anda lepas. Saya menduga itu adalah overlay mount pada khususnya tetapi bisa juga mengikat

1
ThorSummoner

Ini lebih merupakan solusi daripada jawaban, tapi saya mempostingnya jika itu dapat membantu seseorang.

Dalam kasus saya, saya mencoba untuk memodifikasi LVM karena saya ingin membuat partisi/var lebih besar, jadi saya perlu umount itu. Saya mencoba semua komentar dan menjawab di posting ini (terima kasih semua orang dan terutama @ ole-tange untuk mengumpulkan mereka) dan masih mendapat kesalahan "perangkat sibuk".

Saya mencoba membunuh sebagian besar proses dalam urutan yang ditentukan dalam runlevel 0 juga, kalau-kalau urutannya relevan dalam kasus saya, tetapi itu juga tidak membantu. Jadi apa yang saya lakukan adalah membuat saya runlevel khusus (menggabungkan output dari chkconfig ke dalam perintah chkconfig --level baru) yang akan sangat mirip dengan 1 (mode pengguna tunggal) tetapi dengan kemampuan jaringan (dengan jaringan ssh dan xinet).

Ketika saya menggunakan redhat, runlevel 4 ditandai sebagai "tidak digunakan/didefinisikan pengguna", jadi saya menggunakan yang itu, dan jalankan init 4 Dalam kasus saya ini tidak apa-apa karena saya perlu me-reboot server dalam hal apa pun, tetapi mungkin itu adalah kasus orang yang men-tweak disk.

1

Hari ini masalahnya adalah soket terbuka (khusus 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