Pourquoi un instantané Btrfs reste-t-il occupé après l’arrêt de chaque conteneur d’application ?

Un conteneur arrêté peut laisser un instantané Btrfs occupé lorsqu’un autre processus, espace de noms de montage, montage bind, tâche d’envoi ou sous-volume imbriqué le référence encore.

L’arrêt d’un conteneur applicatif met fin à son processus principal, mais ne prouve pas que chaque montage associé, processus auxiliaire, shim d’exécution, session shell, tâche de sauvegarde ou espace de noms a libéré le chemin de l’instantané. Btrfs peut également refuser la suppression lorsque la cible est montée, impliquée dans un envoi, configurée comme sous-volume par défaut ou contient des sous-volumes imbriqués. Diagnostiquez la référence exacte avant de forcer un démontage ou de supprimer les données du conteneur.

Confirmer l’objet Btrfs exact et l’erreur

Notez le chemin complet de l’instantané, l’ID du sous-volume, l’ID parent, l’état en lecture seule, l’UUID, l’UUID reçu et le message d’erreur exact lors de la suppression. Vérifiez que le chemin est bien un sous-volume Btrfs et non un répertoire ordinaire situé à l’intérieur de l’un d’eux.

La référence des sous-volumes Btrfs explique que les instantanés sont des sous-volumes et décrit les conditions qui empêchent leur suppression, notamment l’état de sous-volume par défaut et une opération d’envoi active.

Si l’erreur n’est pas EBUSY, suivez la cause réelle de l’échec. Les problèmes d’autorisation, de montage en lecture seule, de sous-volume par défaut et de sous-volume imbriqué nécessitent des vérifications différentes de celles liées à une référence de montage active.

Distinguer l’arrêt du conteneur de sa suppression

Répertoriez les conteneurs dans les états en cours d’exécution, arrêtés, terminés et en cours de suppression. Notez les identifiants des conteneurs qui utilisaient l’instantané via des montages bind, des volumes nommés ou un pilote de stockage Btrfs.

La référence CLI de Docker montre que docker stop envoie un signal au processus principal ; cela ne signifie pas que la définition du conteneur, les métadonnées d’exécution ou toutes les relations de stockage côté hôte ont été supprimées.

Ne supprimez pas l’instantané simplement parce que l’interface de l’application indique que la pile est arrêtée. Vérifiez si une stratégie de redémarrage, un assistant de contrôle d’état, un shell exec, un conteneur secondaire ou un processus du moteur de conteneurs existe encore.

Inspecter les montages dans chaque espace de noms pertinent

Comparez la table des montages de l’hôte avec les espaces de noms de montage du moteur de conteneurs, des assistants associés aux conteneurs arrêtés, des agents de sauvegarde et de tout shell de longue durée ayant accédé au conteneur.

Le manuel Linux explique que les espaces de noms de montage isolent les listes de montages ; un chemin peut donc sembler démonté sur l’hôte tout en restant monté dans l’espace de noms d’un autre processus.

Utilisez les informations de montage propres à chaque processus plutôt que de vérifier uniquement le shell actuel. Un démontage différé depuis l’hôte peut masquer le symptôme sans libérer l’espace de noms qui détient encore la référence.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Rechercher les montages de conteneurs restés actifs dans un autre espace de noms

Identifiez l’ID de processus du moteur de conteneurs, du shim, de l’agent de surveillance ou de l’assistant susceptible de conserver l’espace de noms. Inspectez son arborescence de montages ainsi que le chemin source correspondant à l’instantané Btrfs.

Red Hat documente un cas vérifié où un montage situé dans un autre espace de noms provoque des erreurs de nettoyage indiquant que le périphérique ou la ressource est occupé, ce qui correspond à la situation où l’hôte semble libre alors que l’instantané reste référencé.

Ne terminez que l’assistant obsolète identifié avec certitude, ou redémarrez le moteur concerné pendant une fenêtre de maintenance. Tuer des propriétaires d’espaces de noms sans rapport peut interrompre d’autres conteneurs et montages.

Utiliser fuser et les vérifications des descripteurs ouverts en tenant compte des limites des espaces de noms

Vérifiez les fichiers ouverts, les répertoires de travail actuels, les fichiers mappés et les utilisateurs de montage sous le chemin de l’instantané. Exécutez les outils avec les privilèges suffisants et comparez leur liste de processus avec celle du moteur de conteneurs.

Le manuel de fuser de Debian avertit qu’il peut ne pas voir les périphériques blocs montés par des processus appartenant à un autre espace de noms de montage ; un résultat vide ne prouve donc pas que l’instantané est inutilisé.

Vérifiez également les sessions shell dont le répertoire courant se trouve dans l’instantané, les services d’indexation, les antivirus, les lecteurs de sauvegarde et les applications qui suivent les journaux. Fermez un utilisateur confirmé à la fois, puis réessayez la vérification d’état en lecture seule.

Écarter les sous-volumes montés, par défaut, imbriqués et en cours d’envoi

Répertoriez chaque montage correspondant à l’ID du sous-volume de l’instantané, vérifiez le sous-volume par défaut du système de fichiers, énumérez les sous-volumes enfants imbriqués et inspectez les tâches d’envoi Btrfs actives.

ArchWiki conseille de ne pas supprimer un sous-volume monté, ce qui rend indispensables la vérification de l’identité du montage et l’examen de la structure imbriquée avant toute suppression.

L’arrêt des conteneurs applicatifs n’arrête pas un envoi Btrfs indépendant, une réplication d’instantané ou un processus de sauvegarde. Attendez la fin de l’envoi ou arrêtez-le proprement, puis vérifiez à nouveau l’état de l’instantané.

Libérer la référence identifiée et supprimer en toute sécurité

Démontez l’instantané depuis l’espace de noms qui le possède, supprimez ou redémarrez l’objet obsolète du moteur de conteneurs si nécessaire, quittez les répertoires de travail concernés, arrêtez la tâche d’envoi confirmée et supprimez les sous-volumes imbriqués dans l’ordre de leurs dépendances.

L’article de ZimaSpace consacré à la création d’instantanés des données d’applications NAS fournit le contexte complémentaire pour identifier les chemins persistants et les états applicatifs réellement couverts par un instantané de conteneur.

Le problème est résolu lorsqu’aucun espace de noms ni processus ne référence le sous-volume, que l’instantané non par défaut approprié est supprimé via la commande Btrfs prise en charge, que le nettoyage en arrière-plan est terminé et que la pile applicative redémarre avec ses chemins de données actifs prévus intacts.