Sur pi2, gvfs-udisks2-volume-monitor occupait 2 608 Mi de RSS et 2,54 Gi de PSS. Le processus tournait depuis 154 jours, dans la session de bureau de pi.
Sur pi1 et pi3, le même processus pèse 9 Mi et 7 Mi.
C'était le premier consommateur de pi2 : un tiers de sa RAM, invisible du scheduler.
pi2 étant saturé, le moteur Longhorn a manqué son délai de 8 s. ext4 a alors abandonné son journal sur quatre volumes (tools#49).
Mesure du redémarrage (fait à la main sur pi2 le 2026-09-15, 10:17Z)
avant
après
free -m available
1 728 Mi
4 340 Mi
free -m used
6 092 Mi
3 480 Mi
kubectl --context=default top node pi2
6 195 Mi (107 %)
3 754 Mi (65 %)
PSS du processus
2,54 Gi
7,6 Mi (neuf)
Qui le lance (relevé)
C'est une unité utilisateur static : /usr/lib/systemd/user/gvfs-udisks2-volume-monitor.service, Slice=session.slice, PartOf=graphical-session.target.
Son processus parent est le systemd --user de pi (session seat0, bureau lightdm).
Elle est activée par D-Bus : /usr/share/dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.service porte SystemdService=gvfs-udisks2-volume-monitor.service.
Le bus de session tourne en dbus-daemon --session … --systemd-activation.
Le binaire vient du paquet gvfs-daemons.
Ce que fait la PR
Nouveau playbook playbooks/system/gvfs_udisks2.yml, importé par system.yml juste après earlyoom. Il :
masque l'unité en portée globale (systemctl --global mask, lien dans /etc/systemd/user/) ;
arrête l'instance en cours dans la session de pi, s'il y a un gestionnaire utilisateur ;
relit le système vivant : systemctl --global is-enabled doit valoir masked, et pgrep -x gvfs-udisks2-vo doit rendre 1.
Pourquoi masquer plutôt que retirer le paquet : gvfs-daemons porte tout gvfs, dont dépend le bureau de Raspberry Pi OS ; le retirer arracherait des paquets sans rapport. Le masque est ciblé et réversible (systemctl --global unmask). Il suffit, puisque le bus active le service via systemd et qu'une unité masquée ne peut plus être réveillée.
Prix : le gestionnaire de fichiers du bureau ne voit plus les disques ni les clés USB. Rien de Kubernetes, de Longhorn ou d'iSCSI n'en dépend : udisks2 (système) reste en place, seul le moniteur de session est coupé.
Le mot de passe vault est lu via kubectl --context=default. Aucun nœud n'est redémarré.
⚠ Aucune CI de ce dépôt ne couvre ansible/ : iac.yaml ne se déclenche que sur iac/**. Vérification locale faite : ansible-playbook --syntax-check rend 0, et --list-hosts rend pi1, pi2, pi3.
## Pourquoi (arcodange-org/tools#52)
- Sur **pi2**, `gvfs-udisks2-volume-monitor` occupait **2 608 Mi de RSS et 2,54 Gi de PSS**. Le processus tournait depuis 154 jours, dans la session de bureau de `pi`.
- Sur **pi1 et pi3**, le même processus pèse **9 Mi et 7 Mi**.
- C'était le premier consommateur de pi2 : un tiers de sa RAM, invisible du scheduler.
- pi2 étant saturé, le moteur Longhorn a manqué son délai de 8 s. ext4 a alors abandonné son journal sur quatre volumes (tools#49).
## Mesure du redémarrage (fait à la main sur pi2 le 2026-09-15, 10:17Z)
| | avant | après |
|---|---|---|
| `free -m` available | 1 728 Mi | **4 340 Mi** |
| `free -m` used | 6 092 Mi | 3 480 Mi |
| `kubectl --context=default top node pi2` | 6 195 Mi (107 %) | **3 754 Mi (65 %)** |
| PSS du processus | 2,54 Gi | 7,6 Mi (neuf) |
## Qui le lance (relevé)
- C'est une unité utilisateur **`static`** : `/usr/lib/systemd/user/gvfs-udisks2-volume-monitor.service`, `Slice=session.slice`, `PartOf=graphical-session.target`.
- Son processus parent est le `systemd --user` de `pi` (session `seat0`, bureau `lightdm`).
- Elle est **activée par D-Bus** : `/usr/share/dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.service` porte `SystemdService=gvfs-udisks2-volume-monitor.service`.
- Le bus de session tourne en `dbus-daemon --session … --systemd-activation`.
- Le binaire vient du paquet `gvfs-daemons`.
## Ce que fait la PR
- Nouveau playbook `playbooks/system/gvfs_udisks2.yml`, importé par `system.yml` juste après earlyoom. Il :
1. **masque l'unité en portée globale** (`systemctl --global mask`, lien dans `/etc/systemd/user/`) ;
2. arrête l'instance en cours dans la session de `pi`, s'il y a un gestionnaire utilisateur ;
3. **relit le système vivant** : `systemctl --global is-enabled` doit valoir `masked`, et `pgrep -x gvfs-udisks2-vo` doit rendre 1.
- **Pourquoi masquer plutôt que retirer le paquet** : `gvfs-daemons` porte tout gvfs, dont dépend le bureau de Raspberry Pi OS ; le retirer arracherait des paquets sans rapport. Le masque est ciblé et réversible (`systemctl --global unmask`). Il suffit, puisque le bus active le service via systemd et qu'une unité masquée ne peut plus être réveillée.
- **Prix** : le gestionnaire de fichiers du bureau ne voit plus les disques ni les clés USB. Rien de Kubernetes, de Longhorn ou d'iSCSI n'en dépend : `udisks2` (système) reste en place, seul le moniteur de session est coupé.
## Application
Après fusion, sur les 3 Pi seulement :
```
ansible-playbook -i ansible/arcodange/factory/inventory ansible/arcodange/factory/playbooks/system/gvfs_udisks2.yml
```
Le mot de passe vault est lu via `kubectl --context=default`. Aucun nœud n'est redémarré.
⚠ Aucune CI de ce dépôt ne couvre `ansible/` : `iac.yaml` ne se déclenche que sur `iac/**`. Vérification locale faite : `ansible-playbook --syntax-check` rend 0, et `--list-hosts` rend pi1, pi2, pi3.
Refs arcodange-org/tools#52
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sur pi2, gvfs-udisks2-volume-monitor (session de bureau de `pi`) occupait
2,54 Gi de PSS après 154 jours, contre 5 à 9 Mi sur pi1 et pi3. pi2
saturé, le moteur Longhorn a manqué son délai de 8 s et ext4 a abandonné
son journal sur quatre volumes (tools#49). Son redémarrage a rendu 2,6 Gi.
Le playbook masque l'unité utilisateur en portée globale (le bus de
session tourne en --systemd-activation, donc le bus ne peut plus la
réveiller), arrête l'instance en cours, puis relit le masque et l'absence
de processus. Masquer plutôt que retirer `gvfs-daemons`, dont dépend tout
gvfs et le bureau de Raspberry Pi OS.
Refs arcodange-org/tools#52
Co-Authored-By: Claude Opus 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Pourquoi (arcodange-org/tools#52)
gvfs-udisks2-volume-monitoroccupait 2 608 Mi de RSS et 2,54 Gi de PSS. Le processus tournait depuis 154 jours, dans la session de bureau depi.Mesure du redémarrage (fait à la main sur pi2 le 2026-09-15, 10:17Z)
free -mavailablefree -musedkubectl --context=default top node pi2Qui le lance (relevé)
static:/usr/lib/systemd/user/gvfs-udisks2-volume-monitor.service,Slice=session.slice,PartOf=graphical-session.target.systemd --userdepi(sessionseat0, bureaulightdm)./usr/share/dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.serviceporteSystemdService=gvfs-udisks2-volume-monitor.service.dbus-daemon --session … --systemd-activation.gvfs-daemons.Ce que fait la PR
playbooks/system/gvfs_udisks2.yml, importé parsystem.ymljuste après earlyoom. Il :systemctl --global mask, lien dans/etc/systemd/user/) ;pi, s'il y a un gestionnaire utilisateur ;systemctl --global is-enableddoit valoirmasked, etpgrep -x gvfs-udisks2-vodoit rendre 1.gvfs-daemonsporte tout gvfs, dont dépend le bureau de Raspberry Pi OS ; le retirer arracherait des paquets sans rapport. Le masque est ciblé et réversible (systemctl --global unmask). Il suffit, puisque le bus active le service via systemd et qu'une unité masquée ne peut plus être réveillée.udisks2(système) reste en place, seul le moniteur de session est coupé.Application
Après fusion, sur les 3 Pi seulement :
Le mot de passe vault est lu via
kubectl --context=default. Aucun nœud n'est redémarré.⚠ Aucune CI de ce dépôt ne couvre
ansible/:iac.yamlne se déclenche que suriac/**. Vérification locale faite :ansible-playbook --syntax-checkrend 0, et--list-hostsrend pi1, pi2, pi3.Refs arcodange-org/tools#52
🤖 Generated with Claude Code