s-informer-sur-la-tech-www/articles/2026/Comprendre RemoveIPC.md

title, description, tags, date, lastmod, type, category, status

title	description	tags	date	lastmod	type	category	status
Comprendre RemoveIPC	Comprendre le paramètre RemoveIPC dans logind.conf : pourquoi il provoque le crash de vos bases de données PostgreSQL ou Oracle et comment le configurer en production (DevOps).		2026-03-10 08:09	2026-03-10 08:14	article	Guide	terminé

Par Cédrix | Date d'édition : 10 mars 2026

Dans l'écosystème Linux moderne, systemd-logind gère bien plus que de simples ouvertures de sessions. L'un de ses paramètres les plus discrets, mais potentiellement destructeurs, est RemoveIPC. Pour un ingénieur DevOps, comprendre ce réglage est crucial pour garantir la stabilité des bases de données et des applications haute performance.

1. Qu'est-ce que l'IPC (Inter-Process Communication) ?

Avant de parler de suppression, rappelons ce que nous protégeons. L'IPC est un ensemble de mécanismes permettant à des processus distincts de partager des données. Les deux formes les plus courantes gérées par RemoveIPC sont :

• System V IPC : Inclut les segments de mémoire partagée (shm), les files d'attente de messages (msg) et les sémaphores (sem).

• POSIX Shared Memory : Une version plus moderne et normalisée du partage de mémoire.

Ces ressources ne sont pas des fichiers sur le disque, mais des segments résidant directement en RAM.

2. Le rôle de RemoveIPC

Le paramètre RemoveIPC se trouve dans le fichier /etc/systemd/logind.conf. Son rôle est binaire :

Scénario A : RemoveIPC=yes (Défaut sur la majorité des distros)

Lorsqu'un utilisateur se déconnecte et qu'il n'a plus aucune session active, systemd parcourt la table des segments IPC. S'il trouve des segments appartenant à cet utilisateur, il les supprime immédiatement pour libérer la mémoire.

L'intention : Éviter les fuites de mémoire (memory leaks) causées par des applications mal codées qui oublient de nettoyer leurs ressources après fermeture.

Scénario B : RemoveIPC=no

Systemd ignore les segments IPC lors de la fermeture de session. La mémoire reste occupée jusqu'à ce qu'un processus les libère manuellement ou que le serveur redémarre.

---

3. Le "Piège" pour les Bases de Données

C'est ici que le bât blesse pour les DevOps. Imaginons l'architecture suivante :

1. Vous avez un serveur PostgreSQL qui tourne sous l'utilisateur système postgres.

2. Le service démarre au boot et alloue un large segment de Shared Memory pour ses opérations.

3. Un administrateur se connecte en SSH, fait un sudo su - postgres pour vérifier une configuration, puis quitte sa session.

4. Le drame : Au moment où l'admin se déconnecte, systemd-logind voit que l'utilisateur postgres n'a plus de session active. Il déclenche RemoveIPC et supprime la mémoire partagée... alors que le service de base de données est toujours en train de l'utiliser !

Résultat : Crash immédiat de la base de données avec des erreurs de type Illegal storage access ou Bus error.

---

4. Pourquoi est-ce le réglage par défaut ?

On pourrait se demander pourquoi un paramètre aussi risqué est activé par défaut. La réponse tient en deux points :

1. Hygiène système : Sur les serveurs multi-utilisateurs ou les environnements de développement, cela évite que la RAM ne soit saturée par des résidus de processus terminés.

2. Protection des utilisateurs système : Par défaut, systemd est censé ignorer les utilisateurs dont l'UID est inférieur à 1000 (utilisateurs système). Cependant, selon la manière dont les sessions sont ouvertes (via su, sudo ou polkit), cette protection peut parfois être contournée, provoquant le crash.

---

5. Bonnes pratiques

Vérifier l'état actuel

Pour voir si des segments IPC sont actuellement utilisés sur votre machine :

ipcs -a

Modifier la configuration

Si vous gérez des serveurs de bases de données, il est souvent recommandé de désactiver cette option :

1. Éditez le fichier : sudo nano /etc/systemd/logind.conf

2. Décommettez ou ajoutez la ligne :

   [Login]
   RemoveIPC=no
   

3. Redémarrez le démon (attention, cela peut impacter les sessions en cours) :

   sudo systemctl restart systemd-logind
   

Alternative : Utiliser KillUserProcesses

Si votre but est de nettoyer les ressources, préférez parfois jouer avec KillUserProcesses=yes. Cela tuera tous les processus restants de l'utilisateur à la déconnexion, ce qui forcera souvent un nettoyage plus "propre" que la suppression brutale de segments de mémoire.

---

Sur un serveur haute dispo passez RemoveIPC à no.