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 utilisesudo
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 optionspci=nomsi
etpci=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
- 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]
ᦿ