---
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:14
type:
  - article
category:
  - "[[Guide]]"
status: 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 :

```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écommettez ou ajoutez la ligne :
    
    ```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.

---

 **Sur un serveur haute dispo passez `RemoveIPC` à `no`.**