Zatrzymany kontener może sprawić, że migawka Btrfs pozostanie zajęta, gdy odwołuje się do niej inny proces, przestrzeń nazw montowania, montowanie bind, zadanie wysyłania lub zagnieżdżony podwolumin.
Zatrzymanie kontenera aplikacji kończy jego główny proces, ale nie dowodzi, że każde powiązane montowanie, proces pomocniczy, shim środowiska uruchomieniowego, sesja powłoki, zadanie kopii zapasowej lub przestrzeń nazw zwolniły ścieżkę migawki. Btrfs może również odrzucić usunięcie, gdy element docelowy jest zamontowany, bierze udział w wysyłaniu, jest skonfigurowany jako domyślny podwolumin lub zawiera zagnieżdżone podwoluminy. Przed wymuszonym odmontowaniem lub usunięciem danych kontenera zdiagnozuj dokładne odwołanie.
Potwierdź dokładny obiekt Btrfs i błąd
Zapisz pełną ścieżkę migawki, identyfikator podwoluminu, identyfikator nadrzędny, stan tylko do odczytu, UUID, odebrany UUID oraz dokładny błąd usuwania. Potwierdź, że ścieżka jest podwoluminem Btrfs, a nie zwykłym katalogiem wewnątrz podwoluminu.
Dokumentacja odwołująca się do podwoluminów Btrfs wyjaśnia, że migawki są podwoluminami oraz opisuje warunki uniemożliwiające ich usunięcie, w tym status domyślnego podwoluminu i aktywną operację wysyłania.
Jeśli błąd nie jest równy EBUSY, postępuj zgodnie z rzeczywistą przyczyną niepowodzenia. Problemy z uprawnieniami, montowaniem tylko do odczytu, domyślnym podwoluminem i zagnieżdżonymi podwoluminami wymagają innych kontroli niż aktywne odwołanie montowania.
Oddziel zatrzymanie kontenera od jego usunięcia
Wyświetl kontenery w stanach uruchomionym, zatrzymanym, martwym i usuwanym. Zapisz identyfikatory kontenerów, które korzystały z migawki za pośrednictwem montowań bind, nazwanych woluminów lub sterownika pamięci Btrfs.
Dokumentacja CLI Dockera pokazuje, że docker stop wysyła sygnał do głównego procesu; nie oznacza to, że definicja kontenera, metadane środowiska uruchomieniowego ani wszystkie relacje pamięci masowej po stronie hosta zostały usunięte.
Nie usuwaj migawki tylko dlatego, że interfejs aplikacji pokazuje zatrzymany stos. Sprawdź, czy nadal istnieje zasada ponownego uruchamiania, pomocnik kontroli stanu, powłoka exec, kontener pomocniczy lub proces środowiska uruchomieniowego kontenera.
Sprawdź montowania we wszystkich odpowiednich przestrzeniach nazw
Porównaj tabelę montowań hosta z przestrzeniami nazw montowania środowiska uruchomieniowego kontenera, pomocników zatrzymanych kontenerów, agentów kopii zapasowych oraz wszelkich długotrwałych powłok, które weszły do kontenera.
Podręcznik systemu Linux wyjaśnia, że przestrzenie nazw montowania izolują listy montowań, dlatego ścieżka może wyglądać na odmontowaną na hoście, a jednocześnie pozostawać zamontowana w przestrzeni nazw innego procesu.
Korzystaj z informacji o montowaniach właściwych dla procesu zamiast sprawdzać wyłącznie bieżącą powłokę. Leniwe odmontowanie z hosta może ukryć objaw bez zwolnienia przestrzeni nazw, która nadal posiada odwołanie.
Poszukaj montowań kontenera, które przetrwały w innej przestrzeni nazw
Ustal identyfikator procesu środowiska uruchomieniowego kontenera, shima, agenta monitorującego lub pomocnika, który może zachowywać tę przestrzeń nazw. Sprawdź jego drzewo montowań oraz ścieżkę źródłową odpowiadającą migawce Btrfs.
Red Hat opisuje potwierdzony przypadek, w którym montowanie w innej przestrzeni nazw powoduje błędy czyszczenia typu „urządzenie lub zasób zajęty”, co odpowiada sytuacji, gdy host wygląda na wolny, ale migawka nadal ma odwołania.
Kończ tylko potwierdzonego, nieaktualnego pomocnika albo uruchom ponownie odpowiednie środowisko uruchomieniowe w oknie serwisowym. Zabicie niepowiązanych właścicieli przestrzeni nazw może zakłócić działanie innych kontenerów i montowań.
Użyj fuser i kontroli otwartych uchwytów, pamiętając o ograniczeniach przestrzeni nazw
Sprawdź otwarte pliki, bieżące katalogi robocze, zamapowane pliki oraz użytkowników montowania w ścieżce migawki. Uruchom narzędzia z odpowiednimi uprawnieniami i porównaj ich listę procesów z procesami środowiska uruchomieniowego.
Podręcznik fuser w Debianie ostrzega, że narzędzie może nie wykryć urządzeń blokowych zamontowanych przez procesy w innej przestrzeni nazw montowania, dlatego pusty wynik nie dowodzi, że migawka nie jest używana.
Sprawdź również sesje powłoki, których bieżący katalog znajduje się wewnątrz migawki, usługi indeksowania plików, skanery antywirusowe, czytniki kopii zapasowych oraz programy śledzące dzienniki aplikacji. Zamykaj po jednym potwierdzonym użytkowniku i ponawiaj kontrolę stanu tylko do odczytu.
Wyklucz zamontowane, domyślne, zagnieżdżone i wysyłane podwoluminy
Wyświetl wszystkie montowania wskazujące na identyfikator podwoluminu migawki, sprawdź domyślny podwolumin systemu plików, wylicz zagnieżdżone podwoluminy potomne oraz skontroluj aktywne zadania wysyłania Btrfs.
ArchWiki zaleca, aby nie usuwać zamontowanego podwoluminu, dlatego przed usunięciem konieczne jest sprawdzenie tożsamości montowania i układu zagnieżdżenia.
Zatrzymanie kontenerów aplikacji nie zatrzymuje niezależnego wysyłania Btrfs, replikacji migawek ani procesu kopii zapasowej. Poczekaj na zakończenie wysyłania lub zatrzymaj je prawidłowo, a następnie ponownie sprawdź stan migawki.
Zwolnij potwierdzone odwołanie i usuń bezpiecznie
Odmontuj migawkę z przestrzeni nazw, która jest jej właścicielem, w razie potrzeby usuń lub uruchom ponownie nieaktualny obiekt środowiska uruchomieniowego kontenera, opuść katalogi robocze, zatrzymaj potwierdzone zadanie wysyłania i usuń zagnieżdżone podwoluminy w kolejności zależności.
Artykuł ZimaSpace dotyczący tworzenia migawek danych aplikacji NAS zapewnia dodatkowy kontekst pomagający ustalić, które trwałe ścieżki i stany aplikacji faktycznie obejmuje migawka kontenera.
Problem jest rozwiązany, gdy żadna przestrzeń nazw ani proces nie odwołuje się do podwoluminu, właściwa migawka niebędąca domyślnym podwoluminem zostanie usunięta za pomocą obsługiwanego polecenia Btrfs, czyszczenie w tle dobiegnie końca, a stos aplikacji uruchomi się ponownie z niezmienionymi, zamierzonymi ścieżkami aktywnych danych.
Wsparcie i wskazówki
Więcej do przeczytania

Czy Plex może współdzielić kartę graficzną z innym kontenerem Dockera?
Plex i inny kontener często mogą korzystać z tego samego układu GPU, ale należy przetestować obsługę sterowników, mapowanie urządzeń, obciążenie silnika wideo, pamięć oraz...

Jak ustalić, czy błąd Plex pochodzi od klienta, czy od serwera
Odtwórz ten sam przypadek na innym kliencie, porównaj ścieżkę sesji, a następnie zbierz dowody z serwera dopiero wtedy, gdy zakres analizy wskaże, gdzie faktycznie...

Jak skonfigurować pamięć podręczną Plex i tymczasową pamięć na transkodowane pliki
Chroń trwały stan Plex, umieszczając tymczasowe pliki transkodowania na odpowiedniej pamięci lokalnej, a następnie zweryfikuj czyszczenie, ilość wolnego miejsca i zachowanie podczas ponownego uruchamiania.

