vault backup: 2026-03-10 08:12:18

articles/2026/Comprendre RemoveIPC.md

@@ -0,0 +1,116 @@
+---
+title: Comprendre RemoveIPC
+description: "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)."
+tags:
+date: 2026-03-10 08:09
+lastmod: 2026-03-10 08:09
+type:
+  - article
+category:
+  - "[[Guide]]"
+status:
+---
+
+
+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. Guide de configuration (Bonnes pratiques DevOps)
+
+### Vérifier l'état actuel
+
+Pour voir si des segments IPC sont actuellement utilisés sur votre machine :
+
+Bash
+
+```
+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écommentez ou ajoutez la ligne :
+    
+    Ini, TOML
+    
+    ```
+    [Login]
+    RemoveIPC=no
+    ```
+    
+3. Redémarrez le démon (attention, cela peut impacter les sessions en cours) :
+    
+    Bash
+    
+    ```
+    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.
+
+---
+
+## Conclusion
+
+`RemoveIPC` est une fonctionnalité de "nettoyage automatique" qui part d'une bonne intention mais qui ignore le cycle de vie complexe des applications de bases de données. En tant que DevOps, la règle d'or est simple : **Sur un serveur de base de données (Postgres, Oracle, MariaDB), passez `RemoveIPC` à `no`.**