Dlaczego migawka Btrfs pozostaje zajęta po zatrzymaniu każdego kontenera aplikacji?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

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

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.