108 lines
4.7 KiB
Markdown
108 lines
4.7 KiB
Markdown
---
|
|
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`.** |