umount: cihaz meşgul. Neden?

Koşarken umount /pathalıyorum:

umount: /path: device is busy.

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

lsof /path, lsof +f -- /pathve fuser /pathhepsi hiçbir şey döndürmez. fuser -v /pathverir:

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

tüm kullanılmayan dosya sistemlerinde normaldir.

umount -lve umount -fdurumum için yeterince iyi değil.

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

Sorunumun sebebi nfs-kernel-serverdizini ihraç etmekti. nfs-kernel-serverMuhtemelen tarafından listede yok dolayısıyla normal açık dosyaları arkasında gider ve lsofve fuser.

Durduğumda dizine nfs-kernel-servergidebilirdim umount.

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

Eklemek için BruceCran 'ın açıklama yukarıda, bu sorunun benim tezahürü için neden sadece şimdi bir oldu bayat geri döngü monte. Zaten çıktısını kontrol ediyorum fuser -vm <mountpoint>/ ' lsof +D <mountpoint>, mountve cat /proc/mountsbazı eski nfs çekirdek sunucu koşuyordu olmadığı kontrol, teşebbüs, kotaları kapalı (ama başarısız) bir umount -f <mountpoint>ve tüm ama nihayet çıktı kontrol etmeden önce 924 gün çalışma süresini terk kendimi bırakmıştım losetupyapılandırılmış ancak monte edilmemiş iki geridönüşümden oluşan ve eski:

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#

Bir Gentoo forum yayını ayrıca takas dosyalarını potansiyel bir suçlu olarak listeler; Her ne kadar bu günlerde dosya takas etmek oldukça nadir olsa da, çıktılarını kontrol etmek zarar veremez cat /proc/swaps. Kotaların sökülmesini engelleyip engellemeyeceğinden emin değilim - çöreklere sarılıyordum.

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

lsof | grep '/path'

Benim için rahatsız edici süreç chroot içinde çalışan bir servistir. Çünkü chroot içerisindeydi lsofve fuserbulamadı.

Bir chrootta çalışan bir şeyin kaldığından şüpheleniyorsanız sudo ls -l /proc/*/root | grep chroot, suçluyu bulur ("chroot" u chroot'un yolu ile değiştirin).

Dosyaları aç

Açık dosyalar içeren işlemler olağan suçlulardır. Onları göster:

lsof +f -- <mountpoint or device>

Kullanmanın bir avantajı vardır /dev/<device>ziyade /mountpointbir mountpoint bir sonra kaybolacaktır: umount -lya da kalıbı oluşturulmuş bir mount tarafından gizlenmiş olabilir.

fuserAyrıca kullanılabilir, ama aklıma lsofdaha yararlı bir çıktı var. Ancak fuser, dramalarınıza neden olan süreçleri öldürmek konusunda faydalıdır, böylece hayatınıza devam edebilirsiniz.

Dosyaları listele <mountpoint>(yukarıdaki uyarıya bakın):

fuser -vmM <mountpoint>

Yalnızca yazma için açık dosyalar ile etkileşimli olarak öldür

fuser -vmMkiw <mountpoint>

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

fuser -vmMk <mountpoint>

Mountpoints

Suçlu, çekirdeğin kendisi olabilir. Çalıştırmaya çalıştığınız dosya sistemine bağlı başka bir dosya sistemi, umountüzüntüye neden olacaktır. Şununla kontrol et:

mount | grep <mountpoint>/

Geri döngü montajları için ayrıca aşağıdakilerin çıkışını kontrol edin:

losetup -la

Anonim düğümler (Linux)

Anonim inode'lar şu şekilde oluşturulabilir:

• Geçici dosyalar ( openile O_TMPFILE)
• saatler inotify
• [Eventfd]
• [Eventpoll]
• [Timerfd]

Bunlar pokemon en zor türüdür ve görünen lsof'ın TYPEolarak sütun a_inode(belgelenmemiş lsofadam sayfası ).

İçeri girmeyecekler lsof +f -- /dev/<device>, bu yüzden yapmanız gerekenler:

lsof | grep a_inode

İsimsiz inode'ları tutan öldürme işlemleri için, bakınız: Mevcut inotify saatlerini listeleyiniz (yol adı, PID) .

Kaynaştırıcının bir montaj açıklığını tutan PID'leri bildirmesi için

fuser -m /path

Kök dosya sisteminin normalde salt okunur olduğu tescilli bir sistemimiz var. Bazen, dosyalar kopyalandığında, yeniden okuma-yazma yeniden yapılır:

mount -oremount,rw /

Ve sonra tekrar monte edildi:

mount -oremount,ro /

Ancak bu sefer mount, mount: / is busyhatayı vermeye devam etti . Bunun nedeni , dosya sistemi okuma-yazma yapılırken yürütülen bazı komutlarla değiştirilen bir dosyaya açık bir tanımlayıcı tutan bir işlemdir . lsof -- /Çıktıdaki önemli satır şöyle olur (isimler değiştirildi):

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

DELÇıktıdakilere dikkat edin . Sadece silinen dosyaya tutulan işlemi yeniden başlatmak sorunu çözdü.

lsofve fuserbana da bir şey vermedi.

Tüm olası dizinleri .old olarak yeniden isimlendirme ve yeniden başlatma işleminden sonra, değişiklikler yaptıktan sonra her seferinde sistemi yeniden başlattım.

Bir zamanlar SDCARD tabanlı bir kök dosya sisteminde (Sheeva Plug) disk yazmalarını en aza indirgemek /var/spool/postfixiçin bir bağlantıdan bir link oluşturmuştum /disk2/pers/mail/postfix/varspool.

Bu bağlantı ile, postfixve dovecothizmetleri durdurduktan sonra bile (her ikisi ps auxde netstat -tuanpilgili hiçbir şey göstermedi) yapamadım unmount /disk2/pers.

Sembolik bağlantıyı kaldırdığımda ve doğrudan yeni direklere işaret edecek şekilde postfixve dovecotconfig dosyalarını güncellediğimde /disk2/pers/hizmetleri ve unmountdizini başarıyla durdurabildim .

Bir dahaki sefere çıktılarına 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ı tekrar tekrar listeleyecek (burada başlayarak /var) ve belirli bir hedef bağlama noktasına işaret eden isimleri filtreleyecektir (burada disk2).

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

Kararımı paylaşacağımı düşündüm.

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

Bağlantımın altında beni engelleyen bir çift var bindve overlaybağlarım var, ayırmak istediğiniz bağlanma noktası için tırnağın tamamlandığını kontrol edin. Özellikle bindirme montajı olduğundan şüpheleniyorum ama çok zor olabilirdi.

Bu bir cevaptan daha geçici bir çözümdür, ancak birine yardımcı olması durumunda gönderiyorum.

Benim durumumda / var bölümünü büyütmek istediğim için LVM'yi değiştirmeye çalışıyordum, bu yüzden onu düzeltmem gerekiyordu. Bu yazıdaki yorum ve cevapların hepsini denedim (herkese teşekkürler ve özellikle onları toplamak için @ ole-tange) ve hala "cihaz meşgul" hatasıyla karşılaştım.

İşlemin çoğunu 0 çalışma seviyesinde belirtilen sıraya göre öldürmeye çalıştım, tam da benim durumumla alakalı olsa bile, bu da işe yaramadı. Bu yüzden benim yaptığım şey, (chkconfig'in çıktısını yeni chkconfig - seviye komutlarıyla birleştirerek) 1'e (tek kullanıcı modu) çok benzeyecek ama ssh ağı ve xinet ile olan özel bir çalışma seviyesi oluşturmaktı.

Redhat kullandığım için, runlevel 4 "kullanılmamış / kullanıcı tanımlı" olarak işaretlendi, bu yüzden onu kullandım ve çalıştırdım init 4 . Durumumda, sunucuyu yeniden başlatmam gerekiyordu, ancak muhtemelen bu durumda olacaktı. diskleri çimdikleyen biri.