umount: perangkat sedang sibuk. Mengapa?


172

Saat berlari umount /pathsaya mendapatkan:

umount: /path: device is busy.

Sistem file sangat besar, jadi lsof +D /pathbukan pilihan yang realistis.

lsof /path,, lsof +f -- /pathdan fuser /pathsemuanya tidak menghasilkan apa-apa. fuser -v /pathmemberi:

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

yang normal untuk semua sistem file yang dipasang tidak digunakan.

umount -ldan umount -ftidak cukup baik untuk situasi saya.

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


11
Apakah direktori shell Anda saat ini di jalur mountpoint?
LawrenceC

Tidak. Kemudian fuser akan berkata begitu.
Ole Tange

12
Anda benar-benar ingin fuser -vm /path...
derobert

5
Untuk umount --forceakan berusaha lebih keras untuk meng-unmount dan -vatau -vvvbahkan akan membuka kembali lebih banyak apa masalah dengan mount. Jadi cobalah:umount -vvv --force /babdmount
gaoithe

Jawaban:


139

Tampaknya penyebab masalah saya nfs-kernel-serveradalah mengekspor direktori. The nfs-kernel-servermungkin terjadi di balik file terbuka normal dan dengan demikian tidak terdaftar oleh lsofdan fuser.

Ketika saya menghentikan direktori nfs-kernel-serversaya bisa umount.

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


54
Terima kasih telah menjawab pertanyaan Anda sendiri alih-alih meninggalkannya setelah menerapkan solusi Anda. Jawaban Anda membantu saya memilah pangsa NFS yang diekspor serupa.
Jeff Welling

7
Masalah yang sama ini juga dapat terjadi jika Anda telah mengatur perangkat loopback pada sistem file - misalnya jika / dev / loop0 didukung oleh file di / path.
BCran

1
Saya harus sudo service samba stopterlebih dahulu, jawaban Anda sangat membantu!
malat

1
Posting ini mengingatkan saya bahwa saya menjalankan layanan nfs setelah beberapa jam mencoba mencari tahu ini. Di RHEL6 / CentOS6, gunakan sudo service nfs stopdan Anda mungkin (tidak) perlu melakukannya juga sudo exportfs -uuntuk tidak mengekspor. Ingat untuk saat itu sudo exportfs -rdan sudo service nfs startuntuk mengekspor kembali dan memulai kembali layanan.
code_dredd

1
Dalam kasus saya, tidak perlu menghentikan server nfs, hanya exportfs -udirektori yang dimaksud.
Law29

42

Untuk menambahkan komentar BruceCran di atas, penyebab manifestasi saya tentang masalah ini sekarang adalah mountback basi basi . Saya sudah memeriksa output dari / , dan , memeriksa apakah beberapa nfs-kernel-server lama berjalan, mematikan kuota, mencoba (tetapi gagal) dan semuanya mengundurkan diri untuk mengabaikan waktu kerja 924 hari sebelum akhirnya memeriksa output dari dan menemukan dua loopback dikonfigurasi-tapi-tidak-basi dikonfigurasi: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

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#

Sebuah Gentoo posting forum juga daftar swapfiles sebagai pelakunya potensial; meskipun bertukar ke file mungkin cukup langka hari ini, tidak ada salahnya untuk memeriksa output dari cat /proc/swaps. Saya tidak yakin apakah kuota dapat mencegah unmount - saya mencengkeram sedotan.


12
Semua waktu uptime 924 hari berarti Anda perlu memperbarui patch kernel Anda :-)
w00t

1 untuk menyebutkan file swap, mereka melakukan blok unmounting, dan cukup banyak yang tidak terdeteksi jika Anda tidak memeriksa mereka secara langsung.
P.Péter

22

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'

1
lsof / path hanya melihat path.
Ole Tange

7
Saya tidak mengatakan lsof /path, kataku lsof | grep '/path'. Perbedaannya adalah bahwa lsof tanpa argumen menunjukkan semua file yang terbuka menggunakan semacam tabel cache, dan grep sangat cepat dalam mencari melaluinya. Hal-hal yang Anda coba dengan lsof membuatnya memindai melalui sistem file yang membutuhkan waktu lama.
Caleb

1
Seperti yang saya katakan: lsof /pathmelihat jalannya saja. Itu tidak melihat setiap file. Seringkali jauh lebih cepat daripada lsof | grep /path(dalam tes tidak ilmiah saya itu YMMV 20 kali lebih cepat) karena tidak melihat semua file yang terbuka tetapi hanya file untuk jalur itu.
Ole Tange

Saya tidak yakin apa perbedaan teknisnya, tetapi ketika menyelidiki basi NFS mount, lsof /pathtidak menghasilkan apa-apa selain lsof | grep /pathmenunjukkan kepada saya proses yang memegang file yang terbuka dan mencegah saya dari unmount volume.
dpw

20

Bagi saya, proses yang menyinggung adalah daemon yang berjalan di chroot. Karena itu di chroot, lsofdan fusertidak akan menemukannya.

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


1
Nice, dan di FreeBSD saya melakukan ini: di sudo ls -l /proc/*/status | grep HOSTmana HOST adalah nama host penjara
JGurtz

1
Di sistem saya (Mint Qiana) lsof /mountpointdan fuser /mountpointkeduanya menemukan proses bahkan jika chroot.
Ole Tange

10

Buka file

Proses dengan file terbuka adalah biang keladinya. Perlihatkan mereka:

lsof +f -- <mountpoint or device>

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

fuserjuga dapat digunakan, tetapi menurut saya lsofmemiliki output yang lebih berguna. Namun fuserberguna 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 menghitung ulang read-only ( mount -o remount,ro <mountpoint>), aman (r) untuk mematikan semua proses yang tersisa:

fuser -vmMk <mountpoint>

Mountpoints

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

mount | grep <mountpoint>/

Untuk pemasangan loopback, periksa juga output dari:

losetup -la

Inode anonim (Linux)

Inode anonim dapat dibuat oleh:

  • File sementara ( opendengan O_TMPFILE)
  • batalkan jam tangan
  • [eventfd]
  • [eventpoll]
  • [timerfd]

Ini adalah jenis yang paling sulit dipahami dari pokemon, dan muncul di lsof's TYPEkolom sebagai a_inode(yang didokumentasikan di lsofhalaman manual ).

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

lsof | grep a_inode

Untuk mematikan proses yang menyimpan inode anonim, lihat: Daftar jam tangan yang tidak berizin saat ini (pathname, PID) .


5

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

fuser -m /path

2
Benar, tetapi tidak relevan: lsof /pathmemberikan daftar PID yang sama dengan fuser -m /path.
Gilles

fuser -M /pathakan memeriksa apakah /pathada mountpoint.
user3804598

5

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

mount -oremount,rw /

Dan kemudian dipasang kembali:

mount -oremount,ro /

Namun kali ini, mountterus memberikan mount: / is busykesalahan. Itu disebabkan oleh proses memegang deskriptor terbuka ke file yang telah digantikan oleh beberapa perintah, yang dieksekusi ketika sistem file itu baca-tulis. Baris penting dari lsof -- /keluaran adalah (nama telah diubah):

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

Perhatikan DELdalam output. Cukup memulai kembali proses menahan file yang dihapus menyelesaikan masalah.


3
Jadi ringkasannya adalah: proses membuka file yang telah dihapus. Masukan yang bagus.
Ole Tange

4

lsofdan fusertidak memberi saya apa-apa juga.

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 (terkait dengan postfix) yang bertanggung jawab.

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

Dengan symlink ini, bahkan setelah menghentikan postfixdan dovecotlayanan (baik ps auxdan netstat -tuanptidak menunjukkan apa pun yang terkait) saya tidak bisa unmount /disk2/pers.

Ketika saya dihapus symlink dan memperbarui postfixdan dovecotconfig file untuk menunjuk langsung ke dirs baru /disk2/pers/saya bisa berhasil menghentikan layanan dan unmountdirektori.

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 pemasangan target tertentu (di sini disk2).


3

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 cangkangnya bahkan tidak sedang duduk di direktori yang terpasang. Membunuh sesi-sesi shell lainnya telah memperbaiki masalah ini untuk saya.

Hanya berpikir saya akan membagikan resolusi saya.


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

Saya memiliki beberapa binddan overlaytunggangan di bawah tunggangan yang menghalangi saya, periksa penyelesaian tab untuk titik pemasangan yang ingin Anda lepas. Saya menduga itu adalah overlay mount pada khususnya tetapi bisa juga mengikat


1

Ini lebih merupakan solusi daripada jawaban, tapi saya mempostingnya kalau-kalau itu bisa 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 ok karena saya perlu me-reboot server dalam hal apa pun, tetapi mungkin itu akan menjadi kasus siapa pun yang men-tweak disk.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.