it-swarm-tr.com

umount: aygıt meşgul. Neden?

Çalışırken umount /path Alırım:

umount: /path: device is busy.

Dosya sistemi çok büyük, bu yüzden lsof +D /path gerçekçi bir seçenek değil.

lsof /path, lsof +f -- /path, ve fuser /path hiçbir şey döndürmez. fuser -v /path şunu verir:

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

kullanılmayan tüm dosya sistemleri için normaldir.

umount -l ve umount -f durumum için yeterince iyi değil.

Çekirdeğin neden bu dosya sisteminin meşgul olduğunu düşündüğünü nasıl anlayabilirim?

186
Ole Tange

Sorunumun nedeni nfs-kernel-server dizini dışa aktarıyordu. nfs-kernel-server muhtemelen normal açık dosyaların arkasına gider ve bu nedenle lsof ve fuser ile listelenmez.

Durduğumda nfs-kernel-server Dizin umount olabilir.

Şimdiye kadar tüm çözümlerin örneklerini içeren bir sayfa yaptım: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

149
Ole Tange

Yukarıda BruceCran 's comment ' a eklemek için, bu sorunun tezahür ettirilmemin nedeni şimdi bayat geri döngü bağlantısı. Zaten fuser -vm <mountpoint>/lsof +D <mountpoint>, mount ve cat /proc/mounts Çıktılarını kontrol etmiştim, bazı eski nfs-çekirdek sunucusunun çalışıp çalışmadığını kontrol ettim, kapalı kotalar, bir umount -f <mountpoint> denedi (ancak başarısız oldu) ve nihayet losetup çıktısını kontrol etmeden ve iki eski yapılandırılmış ancak monte edilmemiş geri döngü bulmadan önce kendimi 924 gün çalışma süresini terk etmeye istifa ettim:

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

sonra

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 Gentoo forum yazısı aynı zamanda takas dosyalarını potansiyel suçlu olarak listeler; dosyalara geçiş yapmak bu günlerde oldukça nadir olsa da, cat /proc/swaps çıktısını kontrol etmek zarar veremez. Kotaların bir demontajı engelleyip engellemeyeceğinden emin değilim - payetlerde tutarak.

42
ZakW

Dosya sisteminde gezinmek için lsof kullanmak yerine, açık dosyaların toplam listesini kullanın ve grep'i kullanın. Daha az doğru olmasına rağmen bu getirilerin daha hızlı olması gerektiğini düşünüyorum. İşi yapmalı.

lsof | grep '/path'
24
Caleb

Benim için rahatsız edici süreç bir chroot içinde çalışan bir daemon idi. Bir kökte olduğu için, lsof ve fuser onu bulamazdı.

Bir chroot'ta çalışan bir şeyiniz olduğundan şüpheleniyorsanız, Sudo ls -l /proc/*/root | grep chroot suçlu bulacak ("chroot" yerine "chot" yolu).

23
cibyr

Dosyaları aç

Açık dosyaları olan işlemler olağan suçlulardır. Göster:

lsof +f -- <mountpoint or device>

/dev/<device> Yerine /mountpoint Kullanmanın bir avantajı vardır: umount -l Sonrasında bir bağlama noktası kaybolacak veya üst üste binen bir bağlama parçası tarafından gizlenebilir.

fuser da kullanılabilir, ancak bence lsof daha kullanışlı bir çıktıya sahiptir. Ancak fuser, dramalarınıza neden olan süreçleri öldürmek konusunda faydalıdır, böylece hayatınıza devam edebilirsiniz.

<mountpoint> Üzerindeki dosyaları listeleyin (yukarıdaki uyarıya bakın):

fuser -vmM <mountpoint>

Yalnızca yazma için açık dosyaları olan işlemleri etkileşimli olarak öldürün:

fuser -vmMkiw <mountpoint>

Salt okunur yeniden takıldıktan sonra (mount -o remount,ro <mountpoint>), Kalan tüm işlemleri öldürmek güvenlidir (r):

fuser -vmMk <mountpoint>

Mountpoints

Suçlu, çekirdeğin kendisi olabilir. umount yapmaya çalıştığınız dosya sistemine monte edilmiş başka bir dosya sistemi keder yaratacak. Şununla kontrol et:

mount | grep <mountpoint>/

Geridöngü montajları için aşağıdakilerin çıkışını da kontrol edin:

losetup -la

Anonim inode'lar (Linux)

Anonim düğümler aşağıdakiler tarafından oluşturulabilir:

  • Geçici dosyalar (O_TMPFILE İle open)
  • saatler inotify saatler
  • [Eventfd]
  • [Eventpoll]
  • [Timerfd]

Bunlar en zor pokemon türüdür ve lsof 's TYPE sütununda a_inode ( lsof man sayfası ).

lsof +f -- /dev/<device> 'Da görünmezler, bu nedenle şunları yapmanız gerekir:

lsof | grep a_inode

Anonim inode tutan süreçleri öldürmek için bakınız: Geçerli inotify saatlerini (yol adı, PID) listeleme.

11
Tom Hale

Kaynaştırıcının bir montaj parçasını açık tutan PID'ler hakkında rapor vermesi için -m kullanmanız gerekir

fuser -m /path
5
Patrick

Kök dosya sisteminin normalde salt okunur olduğu özel bir sistemimiz var. Bazen, dosyaların kopyalanması gerektiğinde, okuma-yazma şeklinde yeniden bağlanır:

mount -oremount,rw /

Ve sonra tekrar takıldı:

mount -oremount,ro /

Ancak bu sefer mountmount: / is busy Hatasını vermeye devam etti. Dosya sistemi okuma-yazma sırasında yürütülen bazı komutlar tarafından değiştirilen olan bir dosyaya açık bir tanımlayıcı tutan bir işlemden kaynaklandı. lsof -- / Çıkışındaki önemli satır şu şekildedir (isimler değiştirilmiştir):

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

Çıktıdaki DEL öğesine dikkat edin. Silinen dosya üzerinde bekletme işlemini yeniden başlatmak sorunu çözdü.

5
pdp

lsof ve fuser bana hiçbir şey vermedi.

Tüm olası dizinleri .old olarak yeniden adlandırma işleminden sonra ve her değişiklik yaptıktan sonra sistemi yeniden başlattıktan sonra, sorumlu olan belirli bir dizin (postfix ile ilgili) buldum.

Bir keresinde /var/spool/postfix ila /disk2/pers/mail/postfix/varspool SDCARD tabanlı bir kök dosya sisteminde (Sheeva Plug) disk yazma işlemlerini en aza indirmek için.

Bu sembolik işaretle, postfix ve dovecot hizmetlerini durdurduktan sonra bile (her ikisi de ps aux Hem de netstat -tuanp ile ilgili hiçbir şey göstermedim) unmount /disk2/pers.

Symlink'i kaldırdığımda ve postfix ve dovecot yapılandırma dosyalarını güncellediğimde /disk2/pers/ Hizmetleri ve unmount dizini başarıyla durdurabildim.

Bir dahaki sefere daha yakından bakacağım:

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

Yukarıdaki komut bir dizin ağacındaki tüm sembolik bağlantıları özyinelemeli olarak listeleyecektir (burada /var) ve belirli bir hedef bağlama noktasına (burada disk2) işaret eden adları filtreleyin.

4
captcha

Bu sorunu yaşadım ve arka planda bilmediğim aktif ekran oturumları olduğu ortaya çıktı. Diğer aktif ekran oturumuna bağlandım ve Shell şu anda bağlı dizinde bile oturmuyordu. Diğer Shell oturumlarını öldürmek sorunu benim için düzeltti.

Sadece kararımı paylaşacağımı düşündüm.

3
colemanm

Bağlantımın altında beni engelleyen bind ve overlay bağlantım var, bağlantısını kesmek istediğiniz bağlama noktası için sekme tamamlandığını kontrol edin. Özellikle bindirme montajı olduğundan şüpheliyim ama bağlamalar da olabilirdi

1
ThorSummoner

Bu, bir yanıttan daha çok bir çözümdür, ancak birisine yardımcı olması durumunda gönderirim.

Benim durumumda/var bölümünü daha büyük yapmak istediğim gibi LVM'yi değiştirmeye çalışıyordum, bu yüzden onu taklit etmeliydim. Tüm yorum çalıştı ve cevap bu yazı (herkese teşekkürler ve özellikle @ ole-tange onları toplamak için) ve hala "cihaz meşgul" hatası var.

İşlemlerin çoğunu 0 çalışma seviyesinde belirtilen sırayla öldürmeyi denedim, siparişin benim durumumla ilgili olması durumunda, ama bu da yardımcı olmadı. Yani bana 1 (tek kullanıcı modu) ama ağ yetenekleri (ssh ağ ve xinet ile) çok benzer olurdu özel bir çalışma düzeyi (chkconfig çıktı yeni chkconfig --level komutları birleştirerek) oluşturmak oldu.

Redhat'ı kullanırken runlevel 4 "kullanılmayan/kullanıcı tanımlı" olarak işaretlendi, bu yüzden onu kullandım ve init 4 Benim durumumda, her durumda sunucuyu yeniden başlatmak için gerekli olduğu gibi Tamam, ama muhtemelen bu diskler tweaking kimse olacak.

1

Bugün sorun açık bir soketti (özellikle 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