cClaude.rocks ☕ Le blog

[Nouvelles technologies, sciences et coups de gueule…]

Menu
nov.
06
2021

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
ඏ

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…

tail -n 2000 /var/log/syslog # Les 2000 dernières lignes de syslog

journalctl --system # Le journal système

journalctl --user # Le journal utilisateur
ඏ

Références

ᦿ

ℹ 2006 - 2021 | 🏠 Retour à l'accueil du domaine | 🏡 Retour à l'accueil du blog