cClaude.rocks ☕ Le blog

Contexte

Trouver ce qui utilise la place sur vos disques n’est pas toujours très simple, il existe de nombreux outils graphiques pour faire cela, mais ils ont un point commun, ils sont très lents…

Méthode

Je vous propose d’utiliser la commande find et la commande du pour résoudre ce problème.

find / -mindepth 1 -maxdepth 1 -exec sudo du -hsx {} \; 2>/dev/null | sort -h

• find / -mindepth 1 -maxdepth 1 — Permet d’obtenir la liste des fichiers et dossier se trouvant à la racine de votre système.
• -exec … \; — Exécute ce la commande « … »
• sudo du -hsx {} — on utilise sudo pour être certain de pouvoir accéder à tout le disque.
• du -hsx {} — du -hsx pour chacune des entrées, -h pour un affichage facile à lire, -s pour avoir le résultat final uniquement et -x oblige a ne pas traiter les points de montage.
• 2>/dev/null — Ignore les erreurs…
• | — Passe le résultat à la commande suivante.
• sort -h — tri le résultat en tenant compte de l’ordre (-h).

Cela vous donnera quelque chose comme :

0       /dev
0       /proc
0       /sys
4,0K    /cdrom
4,0K    /lib64
4,0K    /srv
8,0K    /mnt
16K     /lost+found
44K     /snap
140K    /media
2,0M    /run
2,3M    /tmp
18M     /bin
23M     /sbin
29M     /etc
191M    /root
384M    /boot
1,8G    /lib
1,8G    /opt
2,1G    /swapfile
17G     /home
20G     /usr
134G    /var

On peut compléter ce résultat à l’aide de :

df -h | grep -v '^/dev/loop' | grep -v '^//'

qui donne :

Filesystem                  Size  Used Avail Use% Mounted on
udev                        7,7G     0  7,7G   0% /dev
tmpfs                       1,6G  2,0M  1,6G   1% /run
/dev/nvme0n1p2              234G  180G   42G  82% /
tmpfs                       7,8G   84M  7,7G   2% /dev/shm
tmpfs                       5,0M  4,0K  5,0M   1% /run/lock
tmpfs                       7,8G     0  7,8G   0% /sys/fs/cgroup
/dev/nvme0n1p1              511M  5,3M  506M   2% /boot/efi
/dev/sda1                   916G  776G   95G  90% /mnt/data
tmpfs                       1,6G   64K  1,6G   1% /run/user/1001

Analysons ces résultats, on comprend que c’est le dossier /var qui contient 134G qui utilise l’essentiel des 234G de /.

On peut continuer l’analyse avec :

find /var -mindepth 1 -maxdepth 1 -exec sudo du -hsx {} \; 2>/dev/null | sort -h

voici un extrait du résultat :

…
3,0M    /var/spool
21M     /var/backups
29M     /var/local
134M    /var/crash
179M    /var/cache
2,8G    /var/tmp
20G     /var/lib
118G    /var/log

On poursuit l’analyse :

find /var/log -mindepth 1 -maxdepth 1 -exec sudo du -hsx {} \; 2>/dev/null | sort -h

avec un nouvel extrait :

…
696K    /var/log/wtmp
1,1M    /var/log/wtmp.1
1,9M    /var/log/timeshift
8,9M    /var/log/installer
12M     /var/log/bdc
17M     /var/log/kern.log.2.gz
19M     /var/log/kern.log.4.gz
21M     /var/log/kern.log.3.gz
280M    /var/log/kern.log
395M    /var/log/kern.log.1
4,1G    /var/log/journal
113G    /var/log/syslog

Bon, c’est là que cela sent mauvais, puisque c’est le dossier /var/log/journal et le fichier /var/log/syslog qui prennent l’essentiel de la place.

Dans ce cas, cela indique probablement un gros problème au niveau du système, nettoyer les logs ne suffira probablement pas à le résoudre…

On va cependant supprimer ce fichier tellement gros qu’il n’est plus exploitable, on peut faire cela en redémarrant le service après la suppression du fichier :

sudo rm /var/log/syslog
sudo systemctl restart rsyslog.service

Notez que le fichier /var/log/syslog est une copie de ce qui existe dans /var/log/journal. Vous pouvez donc supprimer le fichier /var/log/syslog sans perte d’information même au niveau des logs, il suffit d’utiliser la commande journalctl qui s’appuie sur le vrai journal.

Bonus : la taille du fichier /var/log/journal

Voir le billet: 💻 Nettoyage du journal de Systemd

Bonus: tracker-miner-fs

• Détail sur `tracker-miner-fs`

  Le contenu du fichier /var/log/syslog

  tail -n 500 /var/log/syslog
  

  est principalement composé des lignes suivantes :

  Nov  6 17:44:10 machine tracker-miner-f[324226]: g_file_has_prefix: assertion 'G_IS_FILE (file)' failed
  Nov  6 17:44:10 machine tracker-miner-f[324226]: g_file_equal: assertion 'G_IS_FILE (file1)' failed
  

  Le fichier s’alimente en permanence, remplissant à nouveau le disque… (ce qui était prévisible)

  Cela provient de tracker-miner-fs, une solution propose de nettoyer le cache, comme suit :

  rm -r ~/.cache/tracker
  

  Après quelque recherche, je trouve une solution un peu plus propre :

  tracker reset --hard
  

  Ensuite on peut contrôler les logs :

  tail -f /var/log/syslog
  

  Et on s’aperçoit que l’erreur n’est plus là (en tous les cas pas aussi souvent). Un problème de plus en moins…

  Pour obtenir de l’aide sur tracker-miner-fs, il faut utiliser la commande :

  tracker --help
  

  pour avoir le détail de la sous-commande :

  tracker help daemon
  tracker help info
  tracker help reset
  tracker help status
  

Bonus: PCIe Bus Error

• Détail

  Mais /var/log/syslog est-il toujours anormalement actif ?

  tail -f /var/log/syslog
  

  Hum, et bien oui…

  Nov  6 18:07:00 machine kernel: [23117.196831] pcieport 0000:00:1d.6: AER: Corrected error received: 0000:03:00.0
  Nov  6 18:07:00 machine kernel: [23117.196930] alx 0000:03:00.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
  Nov  6 18:07:00 machine kernel: [23117.196932] alx 0000:03:00.0: AER:   device [1969:e0b1] error status/mask=00000080/00002000
  Nov  6 18:07:00 machine kernel: [23117.196933] alx 0000:03:00.0: AER:    [ 7] BadDLLP
  

  Après quelques recherches, je comprends que un "PCIe Bus Error" se corrige généralement en modifiant /etc/default/grub (le démarrage du système) pour ajouter les options pci=nomsi et pci=noaer.

  GRUB_CMDLINE_LINUX_DEFAULT="pci=nomsi"
  GRUB_CMDLINE_LINUX="pci=noaer"
  

  Après la modification, vous devez mettre à jour grub à l’aide de :

  sudo update-grub
  

  Et là un redémarrage s’impose…

Bonus : Recherche des fichiers posant problème pour le tracker

• Détail

  Voici deux commandes qui permettent (plus ou moins) de retrouver les fichiers (probablement corrompus) qui posent problème au tracker.

  cat /var/log/syslog |
    grep -v 'G_IS_FILE (' |
    grep -i 'file:///' |
    sed 's,.*file://\(.*\),\1,' |
    cut -d')' -f1 |
    cut -d"'" -f1
  

  journalctl --user --unit=tracker-miner-fs.service -o json -r -n 50000 |
    jq -r \
    --arg mesg1 "g_file_equal: assertion 'G_IS_FILE (file2)' failed" \
    --arg mesg2 "g_file_has_prefix: assertion 'G_IS_FILE (prefix)' failed" \
    'select( .MESSAGE == $mesg1 | not ) | select( .MESSAGE == $mesg2 | not ) | .MESSAGE' |
    grep 'file:' |
    sed 's,.*file://\(.*\),\1,' |
    cut -d')' -f1 |
    cut -d"'" -f1
  

Surveiller les journaux

Pensez à surveiller le journal de vos machines, soit à la main, soit à l’aide de scripts, mais s’ils augmentent de manière inattendue il y a probablement au moins une erreur à résoudre…

journalctl --lines=2000

tail -n 2000 /var/log/syslog

journalctl --system # Le journal système

journalctl --user # Le journal utilisateur

Références

• tracker-miner-fs crashes
• large syslog and kern.log files
• What causes this? pcieport 0000:00:03.0: PCIe Bus Error: AER / Bad TLP
• PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e5(Receiver ID)
• Issues with "PCIe Bus Error: severity=Corrected" errors? [partially SOLVED]

ᦿ