[Bug] Les archives AUR s’accumulent dans /tmp et contribuent à saturer la RAM #97

New issue

Closed

opened 2026-10-12 01:37:13 +00:00 by mathieu · 0 comments

mathieu commented

2026-10-12 01:37:13 +00:00

Owner

Problème constaté

Après plusieurs mises à jour AUR avec AURoscope, des sources téléchargées et archives de paquets construits restent dans la racine de travail /tmp/auroscope-clones. Mathieu demande que les fichiers temporaires soient nettoyés à la fin des opérations : /tmp ne doit pas devenir un stockage durable d’anciennes archives.

Observation sur la machine le 11 octobre 2026 :

/tmp est un tmpfs, plafonné à environ 7,8 Gio, sur une machine de 15,4 Gio de RAM.
/tmp contenait presque 6 Gio, dont 4,3 Gio dans /tmp/auroscope-clones.
Exemples : chatgpt-desktop 1,1 Gio, lightcraft-bin 488 Mio, pdfcraft-bin 482 Mio, wordcraft-bin 462 Mio. Plusieurs versions anciennes et nouvelles coexistent.
Fichiers présents : archives amont .deb, .zip, .tar.gz/.tar.xz et paquets construits .pkg.tar.zst. Les paquets et sources ChatGPT représentent à eux seuls environ 1,1 Gio.
Les journaux confirment des installations depuis cette racine les 10 et 11 octobre. Aucun processus AURoscope ou makepkg n’était encore actif lors du relevé.
Au début de l’investigation, seulement 450–720 Mio de RAM restaient disponibles, et les 4 Gio de swap zram étaient pleins. Ce stock temporaire contribue fortement à la pression mémoire ; il n’est pas présenté comme son unique cause.

Versions installées : auroscope 0.1.0.r30.g9fdae24-1, paru-git 2.1.0.r68.g7830fac-1, systemd 262-1.

Attendu / demande de Mathieu

Nettoyer les archives téléchargées et produites ainsi que les autres artefacts purement temporaires devenus inutiles à la fin de chaque opération, après la fin des sous-processus et de l’installation.
Couvrir le succès, l’échec, l’annulation et les signaux gérés ; ne pas promettre de nettoyage immédiat après SIGKILL ou une coupure. Traiter le reliquat au démarrage suivant si nécessaire.
Ne jamais supprimer les fichiers d’une autre opération concurrente, des chemins arbitraires ou du contenu utilisateur ; limiter le nettoyage aux artefacts appartenant à l’opération.
Si la conservation d’archives sert réellement de cache, employer un emplacement persistant sur disque, avec une politique explicite de nettoyage, plutôt qu’un stock dans le répertoire temporaire. Respecter la responsabilité de Paru sur les builds et caches, sans ajouter un second gestionnaire de paquets. Un cache durable n’est pas obligatoire si les fichiers sont réellement temporaires et correctement nettoyés.
Le correctif doit rester utile même sur une machine où /tmp est sur disque : déplacer la consommation sur SSD ne justifie pas l’accumulation sans limite.

Préserver l’audit, le contrôle final d’identité, l’état SQLite et les modifications de recette nécessaires. Le nettoyage ne doit pas introduire une régression du scénario « référence locale éditée puis clone disparu » signalé dans #89 (ticket actuellement fermé). Il n’est pas demandé de purger aveuglément tous les clones ni un cache partagé.

Vérification souhaitée

Tests isolés pour les fins d’opération et la concurrence ; répétition de plusieurs mises à jour sans croissance continue du stock d’archives temporaires ; vérification de la racine tmpfs et d’une racine sur disque. La livraison du correctif devra respecter les gates de source épinglée et de paquet installé du dépôt.

Ce ticket rapporte les observations et la demande de nettoyage/cache ; aucun correctif ni changement du montage /tmp n’a été réalisé lors de son ouverture.

with pi 🥧

## Problème constaté Après plusieurs mises à jour AUR avec AURoscope, des sources téléchargées et archives de paquets construits restent dans la racine de travail `/tmp/auroscope-clones`. Mathieu demande que les fichiers temporaires soient nettoyés à la fin des opérations : `/tmp` ne doit pas devenir un stockage durable d’anciennes archives. Observation sur la machine le 11 octobre 2026 : - `/tmp` est un `tmpfs`, plafonné à environ 7,8 Gio, sur une machine de 15,4 Gio de RAM. - `/tmp` contenait presque 6 Gio, dont **4,3 Gio dans `/tmp/auroscope-clones`**. - Exemples : `chatgpt-desktop` 1,1 Gio, `lightcraft-bin` 488 Mio, `pdfcraft-bin` 482 Mio, `wordcraft-bin` 462 Mio. Plusieurs versions anciennes et nouvelles coexistent. - Fichiers présents : archives amont `.deb`, `.zip`, `.tar.gz`/`.tar.xz` et paquets construits `.pkg.tar.zst`. Les paquets et sources ChatGPT représentent à eux seuls environ 1,1 Gio. - Les journaux confirment des installations depuis cette racine les 10 et 11 octobre. Aucun processus AURoscope ou makepkg n’était encore actif lors du relevé. - Au début de l’investigation, seulement 450–720 Mio de RAM restaient disponibles, et les 4 Gio de swap zram étaient pleins. Ce stock temporaire contribue fortement à la pression mémoire ; il n’est pas présenté comme son unique cause. Versions installées : `auroscope 0.1.0.r30.g9fdae24-1`, `paru-git 2.1.0.r68.g7830fac-1`, `systemd 262-1`. ## Attendu / demande de Mathieu 1. Nettoyer les archives téléchargées et produites ainsi que les autres artefacts purement temporaires devenus inutiles à la fin de chaque opération, après la fin des sous-processus et de l’installation. 2. Couvrir le succès, l’échec, l’annulation et les signaux gérés ; ne pas promettre de nettoyage immédiat après SIGKILL ou une coupure. Traiter le reliquat au démarrage suivant si nécessaire. 3. Ne jamais supprimer les fichiers d’une autre opération concurrente, des chemins arbitraires ou du contenu utilisateur ; limiter le nettoyage aux artefacts appartenant à l’opération. 4. Si la conservation d’archives sert réellement de cache, employer un emplacement persistant **sur disque**, avec une politique explicite de nettoyage, plutôt qu’un stock dans le répertoire temporaire. Respecter la responsabilité de Paru sur les builds et caches, sans ajouter un second gestionnaire de paquets. Un cache durable n’est pas obligatoire si les fichiers sont réellement temporaires et correctement nettoyés. 5. Le correctif doit rester utile même sur une machine où `/tmp` est sur disque : déplacer la consommation sur SSD ne justifie pas l’accumulation sans limite. Préserver l’audit, le contrôle final d’identité, l’état SQLite et les modifications de recette nécessaires. Le nettoyage ne doit pas introduire une régression du scénario « référence locale éditée puis clone disparu » signalé dans #89 (ticket actuellement fermé). Il n’est pas demandé de purger aveuglément tous les clones ni un cache partagé. ## Vérification souhaitée Tests isolés pour les fins d’opération et la concurrence ; répétition de plusieurs mises à jour sans croissance continue du stock d’archives temporaires ; vérification de la racine tmpfs et d’une racine sur disque. La livraison du correctif devra respecter les gates de source épinglée et de paquet installé du dépôt. Ce ticket rapporte les observations et la demande de nettoyage/cache ; aucun correctif ni changement du montage `/tmp` n’a été réalisé lors de son ouverture. - with pi 🥧

Rows
Columns