J'ai mon disque primaire 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#
Est-ce que quelques recherches sur Google et 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 pas de fichier ou répertoire aussi gros pour remplir les 84G de mon disque.
Il y a quelques jours, j'ai découvert que le disque était plein à cause d'erreurs .xsession devenues folles. J'ai découvert qu'il s'agissait d'un bogue connu dans Ubuntu et j'ai résolu le problème en créant une ligne crontab supprimant les erreurs .xsession. En fait, je ne l’ai plus dans mon répertoire personnel.
Toute aide, s'il vous plaît?
Le problème avec votre tâche cron est que .xsession_errors
est probablement encore ouvert par certaines applications ou services système, ce qui explique 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 écrites.
Ainsi, le disque se remplira, mais vous ne pouvez plus le voir.
@rinzwind vise exactement ce comportement lorsqu'il suggère (correctement) de supprimer le travail cron et de rechercher les erreurs. C'est le seul moyen de résoudre ce problème correctement.
Pour résoudre ce problème, vous pouvez tronquer le fichier .xsession_errors
avec un fichier 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
Qui remplit mon disque?
depuis que tu fais ça ...
J'ai trouvé qu'il s'agissait d'un bogue connu dans Ubuntu et j'ai résolu le problème en créant une ligne crontab supprimant les erreurs .xsession.
il est impossible de répondre à cette question.
Veuillez suivre les instructions suivantes pour nous obtenir les erreurs dont nous avons besoin:
.xsessions_errors
..xsessions_errors
en utilisant tail -f 100 ~/.xsessions_errors
..xsessions_errors
devrait toujours être évitée).Quand il y a une grande différence (disons plus que quelques pour cent) entre (en tant que root) df -g /some/partition_root
et du -gx /some/partition_root
(-x
dit à du de se limiter à la même partition, utile de vérifier '/' par exemple): il existe probablement un fichier ( s) toujours ouvert sur lequel certains processus écrivent encore, mais que vous avez supprimé sur le disque (par conséquent: le fichier existe toujours tant qu'il est ouvert par les processus et remplit l'espace disque (df -g voit cela) mais il n'y a plus de liens (ni de noms de fichiers) vers ses inodes, du -gx les manque.
Dans votre cas, comparez les résultats de:
df -g /
du -gx /
Pour savoir quels sont les fichiers avec moins de 1 lien (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 sont les processus écrivant dans ces fichiers "fantômes" et agissez en conséquence (vous pourrez peut-être arrêter/démarrer certains d'entre eux et, une fois arrêtés, le fichier sera libéré et son espace libéré, d'autres peuvent nécessiter un redémarrage correct)