Perché uno snapshot Btrfs rimane occupato dopo l’arresto di ogni container applicativo?
Un container arrestato può lasciare occupato uno snapshot Btrfs quando un altro processo, uno spazio dei nomi di montaggio, un bind mount, un’attività di invio o un sottovolume annidato continua a farvi riferimento.
Arrestare un container applicativo termina il processo principale, ma non dimostra che ogni montaggio correlato, processo ausiliario, shim del runtime, sessione shell, attività di backup o spazio dei nomi abbia rilasciato il percorso dello snapshot. Btrfs può inoltre rifiutare l’eliminazione quando la destinazione è montata, è coinvolta in un invio, è configurata come sottovolume predefinito o contiene sottovolumi annidati. Diagnostica il riferimento esatto prima di forzare uno smontaggio o eliminare i dati del container.
Conferma l’oggetto Btrfs esatto e l’errore
Registra il percorso completo dello snapshot, l’ID del sottovolume, l’ID del genitore, lo stato di sola lettura, l’UUID, l’UUID ricevuto e l’errore esatto di eliminazione. Conferma che il percorso sia un sottovolume Btrfs e non una normale directory al suo interno.
Il riferimento ai sottovolumi Btrfs spiega che gli snapshot sono sottovolumi e documenta le condizioni che ne impediscono l’eliminazione, incluso lo stato di sottovolume predefinito e un’operazione di invio attiva.
Se l’errore non è EBUSY, segui la causa effettiva del problema. Gli errori di autorizzazione, montaggio in sola lettura, sottovolume predefinito e sottovolumi annidati richiedono controlli diversi da quelli relativi a un riferimento di montaggio attivo.
Separa l’arresto del container dalla sua rimozione
Elenca i container negli stati in esecuzione, arrestato, terminato e in fase di rimozione. Registra gli ID dei container che hanno utilizzato lo snapshot tramite bind mount, volumi denominati o un driver di archiviazione Btrfs.
Il riferimento CLI di Docker mostra che docker stop invia un segnale al processo principale; ciò non significa che la definizione del container, i metadati del runtime o ogni relazione di archiviazione sul sistema host siano stati rimossi.
Non eliminare lo snapshot solo perché l’interfaccia dell’applicazione indica che lo stack è arrestato. Verifica se esistono ancora una politica di riavvio, un helper di controllo dello stato, una shell exec, un sidecar o un processo del runtime del container.
Ispeziona i montaggi in ogni spazio dei nomi pertinente
Confronta la tabella dei montaggi dell’host con gli spazi dei nomi di montaggio del runtime del container, degli helper dei container arrestati, degli agenti di backup e di qualsiasi shell persistente che abbia avuto accesso al container.
Il manuale di Linux spiega che gli spazi dei nomi di montaggio isolano gli elenchi dei montaggi, quindi un percorso può risultare non montato sull’host pur rimanendo montato nello spazio dei nomi di un altro processo.
Usa informazioni specifiche per processo sui montaggi invece di controllare solo la shell corrente. Uno smontaggio differito dall’host può nascondere il sintomo senza rilasciare lo spazio dei nomi che mantiene ancora il riferimento.
Cerca montaggi del container sopravvissuti in un altro spazio dei nomi
Identifica l’ID del processo del runtime del container, dello shim, dell’agente di monitoraggio o dell’helper che potrebbe conservare lo spazio dei nomi. Ispeziona il suo albero dei montaggi e il percorso sorgente corrispondente allo snapshot Btrfs.
Red Hat documenta un caso verificato in cui un montaggio in un altro spazio dei nomi causa errori di pulizia relativi a dispositivo o risorsa occupata, in linea con la situazione in cui l’host appare libero ma lo snapshot continua a essere referenziato.
Termina solo l’helper obsoleto accertato oppure riavvia il runtime pertinente durante una finestra di manutenzione. Terminare processi proprietari di spazi dei nomi non correlati può interrompere altri container e montaggi.
Usa fuser e i controlli degli handle aperti tenendo conto dei limiti degli spazi dei nomi
Controlla i file aperti, le directory di lavoro correnti, i file mappati e gli utenti dei montaggi nel percorso dello snapshot. Esegui gli strumenti con privilegi sufficienti e confronta l’elenco dei processi con quelli del runtime.
Il manuale di fuser di Debian avverte che potrebbe non rilevare i dispositivi a blocchi montati da processi in uno spazio dei nomi di montaggio diverso; quindi un risultato vuoto non dimostra che lo snapshot sia inutilizzato.
Controlla anche le sessioni shell la cui directory corrente si trova nello snapshot, i servizi di indicizzazione dei file, gli scanner antivirus, i lettori di backup e i processi che seguono i log dell’applicazione. Chiudi un utente confermato alla volta e riprova il controllo di stato in sola lettura.
Escludi sottovolumi montati, predefiniti, annidati e in fase di invio
Elenca ogni montaggio che risolve nell’ID del sottovolume dello snapshot, controlla il sottovolume predefinito del filesystem, enumera i sottovolumi figlio annidati e verifica gli invii Btrfs attivi.
ArchWiki consiglia di non eliminare un sottovolume montato, rendendo necessari i controlli sull’identità del montaggio e sulla struttura annidata prima della rimozione.
Arrestare i container delle applicazioni non arresta un invio Btrfs indipendente, la replica di uno snapshot o un processo di backup. Attendi il completamento dell’invio oppure arrestalo correttamente, quindi ricontrolla lo stato dello snapshot.
Rilascia il riferimento accertato ed elimina in sicurezza
Smonta lo snapshot dallo spazio dei nomi che lo possiede, rimuovi o riavvia l’oggetto obsoleto del runtime del container quando opportuno, esci dalle directory di lavoro, arresta l’attività di invio confermata ed elimina i sottovolumi annidati nell’ordine delle dipendenze.
L’articolo di ZimaSpace sugli snapshot dei dati delle app NAS fornisce il contesto aggiuntivo per identificare quali percorsi persistenti e stati dell’applicazione copra effettivamente uno snapshot del container.
Il problema è risolto quando nessuno spazio dei nomi o processo fa riferimento al sottovolume, lo snapshot non predefinito corretto viene eliminato tramite il comando Btrfs supportato, la pulizia in background termina e lo stack dell’applicazione si riavvia mantenendo intatti i percorsi previsti dei dati attivi.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
