umount: urządzenie jest zajęte. Dlaczego?

Podczas biegania umount /pathotrzymuję:

umount: /path: device is busy.

System plików jest ogromny, więc lsof +D /pathnie jest realistyczną opcją.

lsof /path, lsof +f -- /pathi fuser /pathwszyscy nic nie zwracają. fuser -v /pathdaje:

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

co jest normalne dla wszystkich nieużywanych zamontowanych systemów plików.

umount -li umount -fnie jest wystarczająco dobry dla mojej sytuacji.

Jak dowiedzieć się, dlaczego jądro uważa, że ​​ten system plików jest zajęty?

Wygląda na to, że przyczyną mojego problemu nfs-kernel-serverbyło eksportowanie katalogu. nfs-kernel-serverPrawdopodobnie idzie za normalne otwartych plików, a zatem nie znajduje się na liście lsofi fuser.

Kiedy zatrzymałem nfs-kernel-server, mogłem umountkatalog.

Stworzyłem stronę z przykładami wszystkich dotychczasowych rozwiązań: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

Aby dodać do BruceCran „s komentarzu powyżej, przyczyną mojego przejaw tego problemu właśnie teraz był nieświeży zamontować sprzężenia zwrotnego. Ja już sprawdzone wyjście fuser -vm <mountpoint>/ lsof +D <mountpoint>, mounti cat /proc/mounts, sprawdził, czy jakiś stary nfs-kernel-server został uruchomiony, wyłączony kwot, próbował (ale nie powiodło się) A umount -f <mountpoint>i wszystkich, ale pogodziłem się do porzucenia uptime 924 dni, zanim wreszcie sprawdzenie wyjście od losetupi znalezienie dwóch przestarzałych skonfigurowany ale-nie-montowane loopback:

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

następnie

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#

Gentoo forum po wymienia także swapfiles jako potencjalnego sprawcy; chociaż obecnie wymiana plików jest prawdopodobnie dość rzadka, nie może zaszkodzić sprawdzić wyjście cat /proc/swaps. Nie jestem pewien, czy kwoty mogłyby kiedykolwiek zapobiec odmontowaniu - trzymałem się słomy.

Zamiast używać lsof do przeszukiwania systemu plików, po prostu użyj całkowitej listy otwartych plików i grep. Uważam, że ten zwrot musi być szybszy, chociaż jest mniej dokładny. Powinno to zakończyć pracę.

lsof | grep '/path'

Dla mnie proces obrażania był demonem działającym w chroot. Ponieważ był w chroot lsofi fusernie mógł go znaleźć.

Jeśli podejrzewasz, że coś zostało w chroocie, sudo ls -l /proc/*/root | grep chrootznajdziesz winowajcę (zastąp „chroot” ścieżką do chroota).

Otwórz pliki

Procesy z otwartymi plikami są zwykle sprawcami. Wyświetl je:

lsof +f -- <mountpoint or device>

Zaletą używania /dev/<device>zamiast jest /mountpoint: punkt montowania zniknie po umount -llub może zostać ukryty przez nakładane montowanie.

fusermożna również użyć, ale moim zdaniem lsofma bardziej użyteczny efekt. fuserJest to jednak przydatne, jeśli chodzi o zabijanie procesów powodujących twoje dramaty, abyś mógł dalej żyć.

Wyświetl listę plików <mountpoint>(patrz zastrzeżenie powyżej):

fuser -vmM <mountpoint>

Interaktywnie zabijaj tylko procesy z plikami otwartymi do zapisu:

fuser -vmMkiw <mountpoint>

Po ponownym zamontowaniu tylko do odczytu ( mount -o remount,ro <mountpoint>) można bezpiecznie (r) zabić wszystkie pozostałe procesy:

fuser -vmMk <mountpoint>

Punkty montażowe

Winowajcą może być samo jądro. Inny system plików zamontowany w systemie plików, który próbujesz umountwywołać, jest smutny. Sprawdź z:

mount | grep <mountpoint>/

W przypadku montowania w pętli zwrotnej sprawdź także dane wyjściowe:

losetup -la

Anonimowe i-węzły (Linux)

Anonimowe i-węzły mogą być tworzone przez:

• Pliki tymczasowe ( openz O_TMPFILE)
• inotify zegarki
• [eventfd]
• [eventpoll]
• [timerfd]

Są to najbardziej nieuchwytne typu pokemon i pojawiają się w lsof„S TYPEkolumnę jako a_inode(który Undocumented w lsofstronę człowieka ).

Nie pojawią się w lsof +f -- /dev/<device>, więc musisz:

lsof | grep a_inode

Aby dowiedzieć się więcej o procesach zabijania posiadających anonimowe i-węzły, patrz: Lista aktualnych zegarów inotify (ścieżka, PID) .

Aby utrwalacz mógł zgłaszać PID-y, w których mocowanie jest otwarte, musisz użyć -m

fuser -m /path

Mamy zastrzeżony system, w którym główny system plików jest zwykle tylko do odczytu. Czasami, gdy pliki muszą zostać skopiowane, jest ponownie montowane do odczytu i zapisu:

mount -oremount,rw /

A potem ponownie zamontował:

mount -oremount,ro /

Tym razem jednak mountciągle podawałem mount: / is busybłąd. Było to spowodowane procesem trzymania otwartego deskryptora pliku, który został zastąpiony przez jakąś komendę, która została wykonana, gdy system plików był w trybie odczytu-zapisu. Ważnym wierszem lsof -- /danych wyjściowych jest (nazwy zostały zmienione):

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

Zwróć uwagę DELna wynik. Ponowne uruchomienie procesu zatrzymującego usunięty plik rozwiązało problem.

lsofi fusernic mi też nie dał.

Po zmianie nazwy wszystkich możliwych katalogów na .old i ponownym uruchomieniu systemu za każdym razem, gdy dokonałem zmian, znalazłem jeden konkretny katalog (związany z postfiksem), który był odpowiedzialny.

Okazało się, że kiedyś utworzyłem dowiązanie symboliczne od /var/spool/postfixdo /disk2/pers/mail/postfix/varspoolw celu zminimalizowania zapisów na dysku w głównym systemie plików opartym na SDCARD (wtyczka Sheeva).

Z tym dowiązaniem symbolicznym nawet po zatrzymaniu usług postfixi dovecot(zarówno, ps auxjak i netstat -tuanpnie pokazując niczego związanego) nie byłem w stanie unmount /disk2/pers.

Kiedy usunąłem dowiązanie symboliczne i zaktualizowałem pliki postfixi dovecotconfig, aby wskazywały bezpośrednio na nowe katalogi, /disk2/pers/byłem w stanie z powodzeniem zatrzymać usługi i unmountkatalog.

Następnym razem przyjrzę się dokładniej wynikowi:

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

Powyższe polecenie rekurencyjnie wyświetli listę wszystkich dowiązań symbolicznych w drzewie katalogów (tutaj zaczynając od /var) i odfiltruje te nazwy, które wskazują na konkretny docelowy punkt montowania (tutaj disk2).

Miałem ten problem i okazało się, że w tle były aktywne sesje ekranowe, o których nie wiedziałem. Połączyłem się z inną aktywną sesją ekranu, a jej powłoka nawet nie znajdowała się w zamontowanym katalogu. Zabicie tych innych sesji powłoki rozwiązało problem.

Pomyślałem, że podzielę się swoją rezolucją.

Dzisiaj problemem było otwarte gniazdo (konkretnie 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

Mam kilka bindi overlaymocowań pod moim wierzchowcem, które mnie blokowały, sprawdź zakończenie zakładki dla punktu montowania, który chcesz odmontować. Podejrzewam, że w szczególności była to nakładka wierzchnia, ale mogła to być również oprawa

Jest to bardziej obejście niż odpowiedź, ale zamieszczam je na wypadek, gdyby mogło komuś pomóc.

W moim przypadku próbowałem zmodyfikować LVM, ponieważ chciałem powiększyć partycję / var, więc musiałem ją umountować. Próbowałem wszystkich skomentowanych i odpowiedziałem w tym poście (dziękuję wszystkim, a zwłaszcza @ ole-tange za ich zebranie) i nadal dostaję błąd „urządzenie jest zajęte”.

Próbowałem też zabić większość procesów w kolejności określonej na poziomie uruchamiania 0, na wypadek, gdyby kolejność była odpowiednia w moim przypadku, ale to też nie pomogło. Więc stworzyłem niestandardowy poziom uruchamiania (łącząc dane wyjściowe chkconfig z nowymi poleceniami chkconfig --level), który byłby bardzo podobny do 1 (tryb pojedynczego użytkownika), ale z możliwościami sieciowymi (z siecią ssh i xinet).

Ponieważ korzystałem z narzędzia redhat, poziom działania 4 jest oznaczony jako „nieużywany / zdefiniowany przez użytkownika”, więc użyłem tego i uruchomiłem. init 4 W moim przypadku było to w porządku, ponieważ w każdym przypadku musiałem zrestartować serwer, ale prawdopodobnie tak będzie każdego, kto poprawia dyski.