Zajęte urządzenie na Umount

Często mam problem z podłączeniem katalogu:

umount / mnt / reż
umount: / mnt / dir: urządzenie jest zajęte

Istnieje wiele powodów, dla których urządzenie jest zajęte. Czasami są uruchomione procesy, które mają otwarte blokady, czasem są inne katalogi zamontowane na górze /mnt/dir.

Moje pytanie:

Jakie są kroki, aby sprawdzić, dlaczego nie można odmontować katalogu.

Wiem, że jest wiele powodów, ale możesz wyjaśnić konkretne rozwiązanie.

[EDYTOWAĆ]

[X] działające procesy na zamontowanych woluminach.
[X] inny wolumin jest zamontowany na woluminie, który chcemy odmontować
[_] NFS blokuje wolumin, który chcemy odmontować

Sposób sprawdzenia to fuser -vm /mnt/dir, który należy uruchomić jako root. Powie ci, które procesy uzyskują dostęp do punktu podłączenia.

Alternatywą jest lsof /mnt/dir, która pokaże każdy otwarty plik na wierzchowcu. Znowu najlepiej uruchomić jako root.

Możesz uruchomić dowolny z nich jako inny niż root, ale wtedy dane wyjściowe będą ograniczone do twoich procesów - te od innych użytkowników będą po prostu dyskretnie nie pokazywane, nawet jeśli zapobiegną odmontowaniu systemu plików.

Przykład:

Watt:~# fuser -vm /mnt/Zia/src
                     USER        PID ACCESS COMMAND
/mnt/Zia/src:        root     kernel mount /mnt/Zia/src
                     anthony   24909 ..c.. bash
                     anthony   25041 F.c.. gvim

Pole „Dostęp” informuje, w jaki sposób można uzyskać do niego dostęp. W tym przypadku jądro używa go jako mounta (duh, ale odmontowanie będzie w porządku tylko z tym). bashma go jako bieżący katalog roboczy (będzie musiał przejść cddo innego katalogu przed odmontowaniem), a gvim ma zarówno bieżący katalog, jak i plik otwarty (będzie musiał zamknąć tego gvima).

Watt:~# lsof /mnt/Zia/src
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash    24909 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony    6u   REG   0,26    16384 3526219 /mnt/Zia/src/perl/.utf8.c.swp (zia.vpn.home:/home/anthony/src)

Na tym wyjściu możesz zobaczyć bieżące katalogi zarówno dla bash, jak i gvim (jako typ DIR). Możesz także zobaczyć, który plik gvim ma otwarty do zapisu.

Jak wymusić problem:

fuserma -kopcję, która wyśle ​​sygnał (domyślnie:) SIGKILLdo każdego procesu za pomocą mount. Jest to dość silny sposób, aby powstrzymać wierzchowca przed zajęciem. (I oczywiście uważaj na siebie SIGKILL!)

umountma -lopcję wykonania leniwego odmontowania. Podłączenie zostanie usunięte z przestrzeni nazw systemu plików (więc /mnt/Zia/srcw tym przykładzie nie będzie go widać pod ), ale pozostanie zamontowane, więc programy uzyskujące do niego dostęp mogą kontynuować. Kiedy ostatni program, który do niego wejdzie, zakończy się, odmontowanie nastąpi.

Jest jeszcze jedna możliwa do naprawienia przyczyna odmontowania, a serwer NFS przestaje działać. Tutaj możesz użyć umount -f, ale ryzykujesz utratą danych, jeśli to zrobisz. (Klient mógł zapisywać w pamięci podręcznej zapisy, które nie zostały jeszcze potwierdzone przez serwer, i zapisy te zostaną odrzucone. Aplikacje zostały już jednak poinformowane).

Powinieneś użyć:

sudo umount -l <path>

Kolejny wolumin jest zamontowany na woluminie, który chcemy odmontować:

mountKomenda pozwala wiedzieć wszystko tomy zamontowany jeśli invoqued bez argumentów ani opcji (z wyjątkiem -v). Możesz mieć listę aktywnych punktów montowania, dodając trochę perla:

mount | perl -pe 's/.*on (\S+) type.*/\1/'

Następnie po prostu grepuj nad punktem kontrolnym, z którego chcesz odmontować, a będziesz wiedział, czy na tym systemie są zamontowane systemy plików.

mount | perl -pe 's/.*on (\S+) type.*/\1/' | grep '/mnt/dir/'

Masz dwa rozwiązania . Odmontuj systemy plików lub przenieś je za pomocą mount --move olddir newdir(jądro> 2.5.1)

Otwórz pliki

Procesy z otwartymi plikami są zwykle winowajcami. 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

Dla procesów posiadających anonimowych węzłów zabijania, patrz: Lista bieżących Inotify zegarki (pathname, PID) .

Pytanie, jak sprawdzić, czy NFS uzyskuje dostęp do katalogu, który ma zostać odmontowany, nadal pozostaje bez odpowiedzi.

Mam tylko to:

Sprawdź, czy nfsd działa:

pidof nfsd

Pokaż zamontowane katalogi według klientów:

showmount -a

i bez showmountargumentów pokazuje tylko hosty klienta, nawet jeśli są w trybie off-line. Zakładam, że jest to specjalne zachowanie NFS.

Dla mnie problem polegał na tym, że byłem zalogowany więcej niż raz (przez ssh) i na jednym z logowań byłem w wierszu poleceń, gdzie pwd znajdował się w folderze podrzędnym względem punktu montowania.