Podczas biegania umount /path
otrzymuję:
umount: /path: device is busy.
System plików jest ogromny, więc lsof +D /path
nie jest realistyczną opcją.
lsof /path
, lsof +f -- /path
i fuser /path
wszyscy nic nie zwracają. fuser -v /path
daje:
USER PID ACCESS COMMAND
/path: root kernel mount /path
co jest normalne dla wszystkich nieużywanych zamontowanych systemów plików.
umount -l
i umount -f
nie jest wystarczająco dobry dla mojej sytuacji.
Jak dowiedzieć się, dlaczego jądro uważa, że ten system plików jest zajęty?
fuser -vm /path
...--force
będzie starać odmontować i-v
lub-vvv
nawet będzie reaveal więcej na czym polega problem z montażem. Więc spróbuj:umount -vvv --force /babdmount
Odpowiedzi:
Wygląda na to, że przyczyną mojego problemu
nfs-kernel-server
było eksportowanie katalogu.nfs-kernel-server
Prawdopodobnie idzie za normalne otwartych plików, a zatem nie znajduje się na liścielsof
ifuser
.Kiedy zatrzymałem
nfs-kernel-server
, mogłemumount
katalog.Stworzyłem stronę z przykładami wszystkich dotychczasowych rozwiązań: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html
źródło
sudo service samba stop
najpierw, twoja odpowiedź naprawdę pomogła!sudo service nfs stop
i możesz (nie) również zrobić,sudo exportfs -u
aby wyeksportować. Pamiętaj, aby potemsudo exportfs -r
isudo service nfs start
do powrotnego wywozu i ponownie uruchomić usługę.exportfs -u
dany katalog.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>
,mount
icat /proc/mounts
, sprawdził, czy jakiś stary nfs-kernel-server został uruchomiony, wyłączony kwot, próbował (ale nie powiodło się) Aumount -f <mountpoint>
i wszystkich, ale pogodziłem się do porzucenia uptime 924 dni, zanim wreszcie sprawdzenie wyjście odlosetup
i znalezienie dwóch przestarzałych skonfigurowany ale-nie-montowane loopback:następnie
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.źródło
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ę.
źródło
lsof /path
, powiedziałemlsof | grep '/path'
. Różnica polega na tym, że lsof bez argumentów pokazuje wszystkie otwarte pliki przy użyciu pewnego rodzaju tabeli pamięci podręcznej, a grep bardzo szybko je przeszukuje. Rzeczy, których próbowałeś z lsof, powodują, że skanuje on system plików, co zajmuje dużo czasu.lsof /path
patrzy tylko na ścieżkę. Nie patrzy na każdy pojedynczy plik. Często jest znacznie szybszy niżlsof | grep /path
(w moim nienaukowym teście było to 20 razy szybsze YMMV), ponieważ nie patrzy na wszystkie otwarte pliki, ale tylko pliki dla tej ścieżki.lsof /path
nic nie dało,lsof | grep /path
pokazując mi proces, który przechowywał otwarte pliki i uniemożliwiał mi odmontowanie woluminu.Dla mnie proces obrażania był demonem działającym w chroot. Ponieważ był w chroot
lsof
ifuser
nie mógł go znaleźć.Jeśli podejrzewasz, że coś zostało w chroocie,
sudo ls -l /proc/*/root | grep chroot
znajdziesz winowajcę (zastąp „chroot” ścieżką do chroota).źródło
sudo ls -l /proc/*/status | grep HOST
gdzie HOST jest nazwą hosta więzienialsof /mountpoint
ifuser /mountpoint
oboje znajdują proces, nawet jeśli jest chrootowany.Otwórz pliki
Procesy z otwartymi plikami są zwykle sprawcami. Wyświetl je:
Zaletą używania
/dev/<device>
zamiast jest/mountpoint
: punkt montowania zniknie poumount -l
lub może zostać ukryty przez nakładane montowanie.fuser
można również użyć, ale moim zdaniemlsof
ma bardziej użyteczny efekt.fuser
Jest 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):Interaktywnie zabijaj tylko procesy z plikami otwartymi do zapisu:
Po ponownym zamontowaniu tylko do odczytu (
mount -o remount,ro <mountpoint>
) można bezpiecznie (r) zabić wszystkie pozostałe procesy:Punkty montażowe
Winowajcą może być samo jądro. Inny system plików zamontowany w systemie plików, który próbujesz
umount
wywołać, jest smutny. Sprawdź z:W przypadku montowania w pętli zwrotnej sprawdź także dane wyjściowe:
Anonimowe i-węzły (Linux)
Anonimowe i-węzły mogą być tworzone przez:
open
zO_TMPFILE
)Są to najbardziej nieuchwytne typu pokemon i pojawiają się w
lsof
„STYPE
kolumnę jakoa_inode
(który Undocumented wlsof
stronę człowieka ).Nie pojawią się w
lsof +f -- /dev/<device>
, więc musisz:Aby dowiedzieć się więcej o procesach zabijania posiadających anonimowe i-węzły, patrz: Lista aktualnych zegarów inotify (ścieżka, PID) .
źródło
Aby utrwalacz mógł zgłaszać PID-y, w których mocowanie jest otwarte, musisz użyć -m
źródło
lsof /path
zapewnia tę samą listę PID, cofuser -m /path
.fuser -M /path
sprawdzi, czy/path
jest to punkt montowania.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:
A potem ponownie zamontował:
Tym razem jednak
mount
ciągle podawałemmount: / is busy
błą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 wierszemlsof -- /
danych wyjściowych jest (nazwy zostały zmienione):Zwróć uwagę
DEL
na wynik. Ponowne uruchomienie procesu zatrzymującego usunięty plik rozwiązało problem.źródło
lsof
ifuser
nic 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/postfix
do/disk2/pers/mail/postfix/varspool
w 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
postfix
idovecot
(zarówno,ps aux
jak inetstat -tuanp
nie pokazując niczego związanego) nie byłem w stanieunmount /disk2/pers
.Kiedy usunąłem dowiązanie symboliczne i zaktualizowałem pliki
postfix
idovecot
config, aby wskazywały bezpośrednio na nowe katalogi,/disk2/pers/
byłem w stanie z powodzeniem zatrzymać usługi iunmount
katalog.Następnym razem przyjrzę się dokładniej wynikowi:
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).źródło
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ą.
źródło
Dzisiaj problemem było otwarte gniazdo (konkretnie
tmux
):źródło
Mam kilka
bind
ioverlay
mocowań 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źródło
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.źródło