Qui remplit mon disque?


9

J'ai mon disque principal complètement rempli:

root@kodi:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           385M   12M  374M   3% /run
/dev/sda1        88G   84G     0 100% /
tmpfs           1.9G  4.0K  1.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sdb1       917G  429G  442G  50% /media/Cloud
/dev/sdd1       917G  813G   58G  94% /media/Tera
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           385M     0  385M   0% /run/user/1000
root@kodi:/#

/ dev / sda1 est mon disque principal sur lequel ubuntu est installé:

root@kodi:/home/fmf# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=9fab4895-7ccb-4415-b26d-311a17036cda       /               ext4    errors=remount-ro 0       1

# swap was on /dev/sda5 during installation
UUID=7b158f58-e4c1-4717-aa5f-dbeaa79ab93c       none            swap    sw              0       0

UUID=f9079f52-7661-48ad-9bc4-0d2452be66af       /media/Tera     ext2    defaults,nofail 0       0
UUID=fb1f92ee-54f5-44f8-ba92-544e90e6dfeb       /media/Cloud    ext2    defaults,nofail 0       0

root@kodi:/home/fmf#

A fait une recherche Google et a trouvé des commandes pour tester qui est le responsable, mais je ne peux pas savoir qui le remplit:

root@kodi:/# du --exclude=/media -cksh * | sort -hr | head -n 15
du: cannot access 'proc/16360/task/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/task/16360/fdinfo/3': No such file or directory
du: cannot access 'proc/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/fdinfo/3': No such file or directory
1.3T    total
1.3T    media
3.5G    home
3.0G    usr
1010M   var
645M    root
630M    lib
99M     boot
17M     bin
15M     sbin
13M     etc
12M     run
196K    tmp
16K     lost+found
12K     srv
root@kodi:/#

Apparemment, il n'y a aucun fichier ou répertoire si gros pour remplir les 84 Go de mon disque.

Il y a quelques jours, j'ai constaté que le disque était plein en raison d'erreurs .xsession qui sont devenues folles. J'ai trouvé que c'était un bogue connu dans Ubuntu et j'ai résolu de créer une ligne crontab qui supprimait toutes les dix minutes les erreurs .xsession. En fait, pour le moment, je ne l'ai plus dans mon répertoire personnel.

Une aide, s'il vous plaît?


Je n'ai pas d'erreurs .xsession, le cronjob l'a supprimé. Je ne comprends pas ce que vous voulez dire avec les versions officielles d'Ubuntu: j'ai Ubuntu 16.04.1 LTS.
effemmeffe

2
Pour voir s'il y a des fichiers supprimés auxquels un processus accède encore, sudo lsof | grep deleteddonnera des conseils.
ridgy

Le commentaire de @ ridgy est parfait. Si votre .xsession-errorsproblème est en faute, cela le mettra en évidence; sinon, il est très probable que vous vous dirigiez dans la bonne direction.
un CVn du

4
@effemmeffe Sous UNIX, la suppression d'un fichier ne le supprime pas tant que la dernière poignée n'y est pas fermée (c'est pourquoi vous pouvez toujours supprimer un fichier sous UNIX, où sous Windows, vous obtiendrez des erreurs "accès refusé", etc.). Ainsi, le fichier .xsession-errors est toujours , remplissant votre espace disque, car tout ce qui enregistre les erreurs maintient le fichier ouvert. La meilleure façon de résoudre ce problème correctement est de déterminer les causes des erreurs et de les corriger.
Muzer

1
Si le problème concerne les poignées de fichiers ouvertes sur les fichiers supprimés, le redémarrage du système devrait "vous rendre comme par magie" tout l'espace manquant. Cela pourrait être une étape de dépannage utile.
Floris

Réponses:


19

Le problème avec votre cronjob est qu'il .xsession_errorsest très probablement encore ouvert par certaines applications ou services système, c'est pourquoi il sera caché de la table du système de fichiers lors de sa suppression, mais il est toujours sur le disque et des erreurs y seront toujours écrites.
Il va donc remplir le disque, mais maintenant vous ne pouvez plus le voir.

@rinzwind vise exactement ce comportement lorsqu'il suggère (correctement) de supprimer le cronjob et de rechercher les erreurs. C'est le seul moyen de résoudre correctement ce problème.

Pour contourner ce .xsession_errorsproblème, vous pouvez tronquer le fichier avec un cronjob comme celui-ci:

17 */2 * * *  truncate -cs 0 path/to/.xsession_errors

Mais avant de faire cela, vous devriez vraiment essayer de résoudre les problèmes sous-jacents qui créent ces messages d'erreur dans .xsession_errors


@terdon J'aime plus / etc / crontab moi-même: = D
Rinzwind

1
@Rinzwind n'est cependant pas destiné à modifier des fichiers dans le répertoire personnel d'un utilisateur. Exécutez-le au moins en tant qu'utilisateur et non en tant que root!
terdon

@terdon, @rinzwind vous avez tous les deux raison: j'aurais dû faire attention. avoir ce script exécuté en tant qu'utilisateur rootserait imprudent et pourrait créer d'autres problèmes.
Phillip -Zyan K Lee- Stockmann

2
la rotation a le même problème qu'avec la suppression: kodi ne reconnaîtra pas que le fichier est tourné et continuera à y écrire jusqu'à ce que vous lui demandiez de rouvrir ce fichier. (très probablement, il n'y a rien de tel et vous devez redémarrer kodi)
Phillip -Zyan K Lee- Stockmann

1
@terdon truncate -cne créera pas de fichier et ne changera pas la propriété du fichier existant. Il est bon de ne pas l'exécuter en tant que root, mais la propriété du fichier n'est pas une raison.
Hobbs du

10

Qui remplit mon disque?

puisque tu fais ça ...

J'ai trouvé que c'était un bogue connu dans Ubuntu et j'ai résolu la création d'une ligne crontab qui supprimait toutes les dix minutes les erreurs .xsession

il est impossible de répondre à cette question.

Veuillez suivre ce qui suit pour nous obtenir les erreurs que nous devons voir:

  • Supprimez la ligne crontab que vous avez ajoutée et qui la supprime .xsessions_errors.
  • Redémarrez puis vérifiez à partir de la ligne de commande ce qui se remplit en .xsessions_errorsutilisant tail -f 100 ~/.xsessions_errors.
  • Lorsque vous rencontrez des problèmes répétés, copiez-en certains dans votre question.
  • Ajoutez à nouveau la ligne crontab pour pouvoir utiliser votre système.
  • Attendez une solution au problème et appliquez ensuite. Supprimez ensuite à nouveau la ligne crontab (la suppression du .xsessions_errorsfichier doit toujours être évitée).

7
"Lorsque vous rencontrez des problèmes qui se répètent beaucoup, copiez-en certains dans votre question." Non, ce serait une nouvelle question différente.
Courses de légèreté en orbite du

Suivi: j'ai supprimé la crontab et maintenant le fichier .xsession-errors est libre de croître. Mais ce n'est pas. Et mon espace disque est toujours en baisse. Le problème n'était donc pas là. Un redémarrage arrête le disque de manger, mais je voudrais ne pas redémarrer la machine tous les jours. Un indice?
effemmeffe

3

Lorsqu'il y a de grandes différences (disons, plus de quelques pour cent) entre (en tant que root) df -g /some/partition_rootet du -gx /some/partition_root( -xindique à du de se limiter à la même partition, utile pour vérifier '/' par exemple): il y a probablement encore des fichiers ouvert que certains processus écrivent toujours, mais que vous avez supprimé sur le disque (d'où: le fichier existe toujours tant qu'il est ouvert par les processus et remplit l'espace disque (df -g le voit) mais comme il n'y a pas des liens plus longs (ou noms de fichiers) vers ses inodes, du -gx les manque.

Dans votre cas, comparez les sorties de:

df -g /
du -gx /

Pour savoir quels sont les fichiers avec moins de 1 liens (c'est-à-dire les fichiers supprimés mais toujours ouverts):

lsof -nP +L1  /

Vérifiez les noms de processus et les pids pour voir quels processus écrivent dans ces fichiers "fantômes", et agissez en conséquence (certains peuvent être en mesure d'arrêter / démarrer, et lorsqu'ils sont arrêtés, le fichier sera libéré et son espace libéré, d'autres peuvent nécessiter un redémarrage approprié)


df -g n'est pas une commande valide sur mon ubuntu: root @ kodi: / home / fmf # df -g / df: option invalide - 'g'
effemmeffe

@effemmeffe: alors utilisez l'option appropriée (-k si aix, -h dans solaris) et utilisez celle correspondante pour du ...
Olivier Dulac

Je ne peux pas obtenir de votre réponse ce que l'option -g devrait faire, donc je ne peux pas rechercher l'option équivalente, pouvez-vous détailler, s'il vous plaît?
effemmeffe

-g sur linux sur df ou du montre la taille en gigabites
Olivier Dulac

Ce n'est pas dans mon ubuntu. Quoi qu'il en soit, je l'ai, merci.
effemmeffe
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.