Suppression de la mémoire partagée avec ipcrm sous Linux
je travaille avec une application de mémoire partagée, et pour supprimer les segments j'utilise la commande suivante:
ipcrm -M 0x0000162e (this is the key)
Mais je ne sais pas si je fais les bonnes choses, parce que quand je lance ipcs je vois le même segment mais avec la clé 0x0000000. Donc le segment de mémoire est vraiment effacé? Quand j'exécute mon application plusieurs fois, je vois différents segments de mémoire avec la touche 0x000000, comme ceci:
key shmid owner perms bytes nattch status
0x00000000 65538 me 666 27 2 dest
0x00000000 98307 me 666 5 2 dest
0x00000000 131076 me 666 5 1 dest
0x00000000 163845 me 666 5 0
Ce qui se passe réellement? Est le segment de mémoire vraiment supprimé?
Edit: le problème était - comme indiqué ci - dessous dans la réponse acceptée-qu'il y avait deux processus utilisant la mémoire partagée, jusqu'à ce que tout le processus soit fermé, le segment de mémoire ne va pas disparaître.
2 réponses
je me souviens vaguement de mes jours UNIX (AIX et HPUX, j'admets que je n'ai jamais utilisé de mémoire partagée sous Linux) que la suppression marque simplement le bloc comme n'étant plus attachable par les nouveaux clients.
il ne sera physiquement supprimé qu'à un moment donné après qu'il n'y aura plus de processus attachés à lui.
c'est la même chose que pour les fichiers réguliers qui sont supprimés, leurs informations de répertoire sont supprimées mais le contenu du fichier ne disparaît qu'après la fermeture du dernier processus. Cela conduit parfois à enregistrer des fichiers qui occupent de plus en plus d'espace sur le système de fichiers, même après leur suppression car les processus leur écrivent encore, conséquence du "détachement" entre un pointeur de fichier (le zéro ou plusieurs entrées de répertoire pointant vers une inode) et le contenu du fichier (l'inode lui-même).
Vous pouvez voir à partir de votre ipcs sortie que 3 des 4 ont encore des processus attachés de sorte qu'ils n'iront nulle part jusqu'à ce que ces processus se détachent de la mémoire partagée bloc. L'autre attend probablement une fonction de "balayage" pour le nettoyer, mais cela dépendra bien sûr de l'implémentation de la mémoire partagée.
un client bien écrit de mémoire partagée (ou de fichiers journaux pour cette matière) devrait périodiquement se réattaquer (ou se retourner) pour s'assurer que cette situation est transitoire et n'affecte pas le fonctionnement du logiciel.
Vous avez dit que vous avez utilisé la commande suivante
ipcrm -M 0x0000162e (this is the key)
à Partir de la page de man pour ipcrm
-M shmkey Mark the shared memory segment associated with key shmkey for removal. This marked segment will be destroyed after the last detach.
ainsi le comportement des options-M fait exactement ce que vous avez observé, c'est-à-dire mettre le segment à détruire seulement après le dernier détachement.