Nettoyer Kubuntu : supprimer les dumps, rapports de crash et anciens journaux.

Nettoyer Kubuntu : supprimer les dumps, rapports de crash et anciens journaux

Un système Linux n’a généralement pas besoin d’être « nettoyé » aussi agressivement qu’un système Windows. Pourtant, après plusieurs mois d’utilisation, les journaux système, rapports de crash et core dumps peuvent occuper une quantité d’espace non négligeable.

Kubuntu, comme les autres distributions utilisant systemd, dispose de plusieurs mécanismes permettant de conserver les informations nécessaires au diagnostic des problèmes.

L’objectif de ce guide est simple :

Nettoyer Kubuntu sans supprimer aveuglément des fichiers système utiles.

Nous allons voir où se trouvent les rapports de crash, comment identifier les core dumps, comment nettoyer les journaux systemd et comment vérifier ce qui a réellement été récupéré.

—

1. Pourquoi conserver des traces de crash ?

Lorsqu’une application plante, Linux peut conserver plusieurs types d’informations.

Ces données sont utiles pour diagnostiquer un problème :

• application ayant planté ;
• PID du processus ;
• signal ayant provoqué l’arrêt ;
• version du programme ;
• bibliothèques utilisées ;
• informations de backtrace ;
• parfois une image complète de la mémoire du processus.

Ces informations peuvent toutefois prendre de la place.

Le cas le plus spectaculaire est le core dump : il s’agit essentiellement d’une capture de la mémoire d’un processus au moment où celui-ci plante.

Un seul core dump peut donc facilement atteindre plusieurs dizaines, voire centaines de mégaoctets.

—

2. Vérifier les rapports de crash dans /var/crash

Ubuntu et Kubuntu peuvent conserver des rapports de crash dans :

/var/crash/

Commençons par regarder ce qu’il contient :

ls -lah /var/crash/

Une installation propre peut parfaitement afficher :

total 0

Cela signifie simplement qu’il n’y a actuellement aucun rapport de crash stocké dans ce répertoire.

Supprimer les anciens rapports

Si des fichiers sont présents et que vous n’en avez plus besoin :

sudo rm -f /var/crash/*

Attention : ne supprimez pas le répertoire /var/crash lui-même.

—

3. Les core dumps : une autre histoire.

Les core dumps gérés par systemd sont généralement stockés dans :

/var/lib/systemd/coredump/

Vérifions leur taille :

sudo du -sh /var/lib/systemd/coredump/

Puis affichons les fichiers :

sudo ls -lah /var/lib/systemd/coredump/

On peut par exemple trouver un fichier ressemblant à :

core.plasmashell.1000....2468....zst

Le suffixe .zst indique qu’il est compressé avec Zstandard.

Dans un cas réel, un crash de plasmashell peut produire un fichier de plusieurs dizaines de mégaoctets.

—

4. Utiliser coredumpctl pour identifier les crashs.

La commande principale est :

coredumpctl list

Elle affiche notamment :

TIME                         PID   UID   GID  SIG   COREFILE  EXE

Par exemple :

Wed 2026-09-09 19:30:40 CEST  2468  1000  1000  SIGSEGV  present  /usr/bin/plasmashell

Ici :

• PID 2468 est le processus qui a planté ;
• SIGSEGV indique une erreur de segmentation ;
• plasmashell est le programme concerné ;
• present indique que le core dump est encore accessible.

—

5. Examiner un crash avant de le supprimer.

Lorsqu’un crash vient de se produire, il peut être intéressant de conserver temporairement le dump.

Pour afficher ses informations :

coredumpctl info 2468

Le PID doit évidemment être remplacé par celui indiqué par coredumpctl list.

Cette commande peut fournir :

• le programme concerné ;
• la date et l’heure ;
• le signal ;
• le paquet Debian/Ubuntu ;
• le kernel ;
• les bibliothèques chargées ;
• éventuellement une trace permettant d’identifier la cause du crash.

Exemple

Dans notre cas réel, plasmashell avait terminé avec :

Signal: 11 (SEGV)

et appartenait au paquet :

plasma-workspace

Il s’agissait donc bien d’un crash de Plasma et non d’un simple message d’erreur.

—

6. Attention à l’état missing

Après avoir supprimé manuellement un core dump, coredumpctl list peut continuer à afficher le crash.

Par exemple :

SIGSEGV  missing  /usr/bin/plasmashell

Cela ne signifie pas que le fichier occupe encore de l’espace.

Cela signifie que systemd possède encore les métadonnées du crash dans le journal, mais que le fichier de core dump lui-même n’est plus disponible.

C’est un comportement normal.

La documentation de coredumpctl précise justement qu’un core dump peut rester référencé dans le journal alors que son fichier a déjà été supprimé.

—

7. Supprimer un core dump précis.

Les commandes disponibles dans coredumpctl peuvent varier selon la version de systemd.

Il ne faut donc pas supposer que des commandes comme :

coredumpctl purge

ou :

coredumpctl remove

existent sur toutes les installations.

La commande :

coredumpctl --help

permet de vérifier les verbes réellement disponibles.

Sur une installation où le core dump est stocké dans :

/var/lib/systemd/coredump/

on peut identifier précisément le fichier avec :

sudo ls -lah /var/lib/systemd/coredump/

Puis supprimer le fichier identifié, et uniquement celui-là :

sudo rm -f /var/lib/systemd/coredump/NOM_DU_FICHIER.zst

Par exemple :

sudo rm -f /var/lib/systemd/coredump/core.plasmashell.1000....zst

Ne faites pas un rm -rf aveugle de tout le répertoire si vous êtes encore susceptible d’avoir besoin des dumps pour diagnostiquer un problème.

—

8. Vérifier la place occupée par les journaux systemd

Les journaux sont une autre source possible d’accumulation.

Pour connaître leur taille :

journalctl --disk-usage

Exemple :

Archived and active journals take up 330.2M in the file system.

Il est important de comprendre que cette valeur comprend à la fois les journaux archivés et les journaux actifs. journalctl --disk-usage additionne les fichiers du journal actuellement présents sur le disque.

—

9. Nettoyer les journaux de plus de 30 jours.

Pour une machine personnelle, conserver environ un mois d’historique est souvent un bon compromis.

La commande est très simple :

sudo journalctl --vacuum-time=30d

Elle supprime les fichiers de journal archivés plus anciens que la période indiquée. Les journaux actifs ne sont pas supprimés par cette opération.

Après le nettoyage :

journalctl --disk-usage

permet de vérifier le résultat.

Exemple réel

Sur notre installation Kubuntu :

Avant :

Archived and active journals take up 330.2M

Commande :

sudo journalctl --vacuum-time=30d

Résultat :

Vacuuming done, freed 201.6M

Après :

Archived and active journals take up 128.6M

Soit plus de 200 Mo récupérés avec une seule commande.

—

10. Autres méthodes de nettoyage des journaux.

journalctl propose également plusieurs méthodes.

Limiter la taille des journaux archivés

Par exemple :

sudo journalctl --vacuum-size=200M

Cela demande à journald de supprimer les anciens journaux archivés jusqu’à ce que leur taille soit ramenée sous la limite indiquée.

Conserver seulement un certain nombre de fichiers

sudo journalctl --vacuum-files=5

Ces trois options peuvent également être combinées :

sudo journalctl --vacuum-time=30d --vacuum-size=500M

La documentation systemd précise toutefois que le nettoyage porte sur les fichiers archivés : les fichiers de journal actuellement actifs peuvent rester présents.

—

11. Ne pas supprimer /var/log à la main.

Une mauvaise habitude consiste à faire quelque chose comme :

sudo rm -rf /var/log/*

À éviter absolument.

Les journaux servent au diagnostic des problèmes et certains sont gérés activement par systemd, logrotate ou d’autres services.

Utilisez plutôt les outils prévus pour leur gestion :

journalctl

et :

logrotate

selon le type de journal concerné.

—

12. Vérifier la configuration de systemd-coredump.

Pour savoir comment les core dumps sont configurés :

cat /etc/systemd/coredump.conf

Il est également préférable de regarder la configuration réellement appliquée :

systemd-analyze cat-config systemd/coredump.conf

Cette dernière commande permet notamment de prendre en compte les éventuels fichiers de configuration complémentaires.

La configuration de systemd-coredump peut également se trouver dans les répertoires de configuration coredump.conf.d.

—

13. Où sont réellement stockés les core dumps ?

Lorsque Storage=external est utilisé, les core dumps sont normalement enregistrés dans :

/var/lib/systemd/coredump/

La configuration de systemd prévoit également des mécanismes automatiques de limitation de l’espace utilisé et de suppression des anciens dumps.

C’est important : un core dump n’est pas forcément destiné à rester indéfiniment sur le disque.

Il peut être automatiquement supprimé après un certain délai par les mécanismes de maintenance de systemd.

—

14. Vérification complète après nettoyage.

Voici une petite routine que l’on peut utiliser de temps en temps.

Rapports de crash

ls -lah /var/crash/

Core dumps

sudo du -sh /var/lib/systemd/coredump/ 2>/dev/null

Puis :

coredumpctl list

Journaux

journalctl --disk-usage

Espace disque général

df -h /

Cela donne une bonne vue d’ensemble sans toucher à quoi que ce soit.

—

15. Une routine de maintenance simple.

Pour un ordinateur personnel Kubuntu, je recommande surtout de ne pas transformer le nettoyage en corvée.

Une vérification occasionnelle suffit :

ls -lah /var/crash/

sudo du -sh /var/lib/systemd/coredump/ 2>/dev/null

journalctl --disk-usage

Si les journaux deviennent importants :

sudo journalctl --vacuum-time=30d

Et si un programme vient de planter :

coredumpctl list

puis, avant de supprimer le dump :

coredumpctl info PID

—

16. Faut-il vraiment nettoyer Linux ?

Oui, mais pas de la même manière que certains outils de « nettoyage » peuvent le laisser penser.

Linux n’a généralement pas besoin d’un grand nettoyage périodique consistant à supprimer des centaines de fichiers système.

Le principe est plutôt :

observer → identifier → comprendre → supprimer ce qui est réellement inutile.

Les journaux sont utiles.

Les core dumps sont utiles lorsqu’un programme vient de planter.

Les rapports de crash sont utiles pour diagnostiquer les problèmes.

Ils deviennent simplement inutiles lorsque :

• le problème est résolu ;
• le dump a été analysé ;
• les journaux sont beaucoup trop anciens ;
• ou leur taille devient disproportionnée.

—

17. Le nettoyage idéal.

Pour résumer :

# Rapports de crash
ls -lah /var/crash/

# Core dumps
coredumpctl list
sudo du -sh /var/lib/systemd/coredump/

# Journaux systemd
journalctl --disk-usage

# Nettoyer les journaux de plus de 30 jours
sudo journalctl --vacuum-time=30d

# Vérifier le résultat
journalctl --disk-usage

# Vérifier l'espace disque
df -h /

Cette méthode est volontairement prudente.

Elle permet de récupérer de l’espace tout en conservant les informations récentes nécessaires au dépannage.

—

Conclusion :

Un Linux bien entretenu n’est pas nécessairement un Linux où tous les fichiers « anciens » ont été supprimés.

C’est surtout un système où l’on sait ce qui occupe de l’espace et pourquoi.

Avec quelques commandes simples :

coredumpctl list

journalctl --disk-usage

sudo journalctl --vacuum-time=30d

et :

df -h /

on peut maintenir une installation Kubuntu propre sans prendre de risques inutiles.

Et surtout, avant de supprimer un core dump récent, prenez quelques secondes pour l’examiner :

coredumpctl info PID

Un fichier de 50 Mo qui vient d’un crash de Plasma peut être beaucoup plus intéressant comme indice de diagnostic que comme espace disque à récupérer.

Nettoyer, oui. Nettoyer à l’aveugle, non.

StalkerLabs — Break it. Understand it. Document it.