Wer füllt meine Festplatte?

Ich habe meine primäre Festplatte vollständig gefüllt:

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 ist meine primäre Festplatte, auf der Ubuntu installiert ist:

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#

Habe eine Google-Suche durchgeführt und einige Befehle gefunden, um zu testen, wer der Verantwortliche ist, aber ich kann nicht herausfinden, wer sie ausfüllt:

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:/#

Anscheinend gibt es keine Datei oder ein Verzeichnis, die so groß sind, um die 84G meiner Festplatte zu füllen.

Vor einigen Tagen stellte ich fest, dass die Festplatte aufgrund von .xsession-Fehlern, die verrückt wurden, voll war. Ich fand, dass dies ein bekannter Fehler in Ubuntu ist, und löste das Erstellen einer Crontab-Zeile, die alle zehn Minuten .xsession-Fehler löscht. Tatsächlich habe ich es momentan nicht mehr in meinem Home-Verzeichnis.

Hilfe bitte?

Das Problem mit Ihrem Cronjob ist, dass er .xsession_errorshöchstwahrscheinlich immer noch von einigen Anwendungen oder Systemdiensten geöffnet wird, weshalb er beim Löschen aus der Dateisystemtabelle ausgeblendet wird, sich aber immer noch auf der Festplatte befindet und immer noch Fehler darauf geschrieben werden.
Es wird also die Festplatte füllen, aber jetzt können Sie es nicht mehr sehen.

@rinzwind zielt genau auf dieses Verhalten ab, wenn er (richtig) vorschlägt, den Cronjob zu entfernen und nach Fehlern zu suchen. Dies ist die einzige Möglichkeit, dieses Problem ordnungsgemäß zu beheben.

.xsession_errorsUm dieses Problem zu umgehen, können Sie die Datei mit einem Cronjob wie folgt abschneiden:

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

Aber bevor Sie dies tun, sollten Sie WIRKLICH versuchen, die zugrunde liegenden Probleme zu beheben, die diese Fehlermeldungen verursachen .xsession_errors

Wer füllt meine Festplatte?

seit du das machst ...

Ich fand, dass dies ein bekannter Fehler in Ubuntu ist, und löste das Erstellen einer Crontab-Zeile, die alle zehn Minuten .xsession-Fehler löscht

Es ist unmöglich, diese Frage zu beantworten.

Bitte folgen Sie den folgenden Anweisungen, um die Fehler zu erhalten, die wir sehen müssen:

• Entfernen Sie die hinzugefügte Crontab-Linie, die entfernt wird .xsessions_errors.
• Reboot und dann von der Kommandozeile überprüfen , was füllt sich .xsessions_errorsmit tail -f 100 ~/.xsessions_errors.
• Wenn Sie Probleme finden, die häufig wiederholt werden, kopieren Sie einige davon in Ihre Frage.
• Fügen Sie die Crontab-Linie wieder hinzu, damit Sie Ihr System verwenden können.
• Warten Sie auf eine Lösung für das Problem und bewerben Sie sich dann. Entfernen Sie dann die crontab-Zeile erneut (das Löschen der .xsessions_errorsDatei sollte immer vermieden werden).

Wenn es große Unterschiede gibt (z. B. mehr als ein paar Prozent) zwischen (als root) df -g /some/partition_rootund du -gx /some/partition_root( -xweist du an, sich auf dieselbe Partition zu beschränken, nützlich, um beispielsweise '/' zu überprüfen): Es gibt wahrscheinlich noch Dateien geöffnet, auf das einige Prozesse noch schreiben, die Sie jedoch auf der Festplatte gelöscht haben (daher: Die Datei existiert noch, solange sie von den Prozessen geöffnet wird, und füllt den Speicherplatz aus (df -g sieht das), aber es gibt keine längere Links (oder Dateinamen) zu seinen Inodes, du -gx vermisst sie.

Vergleichen Sie in Ihrem Fall die Ausgaben von:

df -g /
du -gx /

So finden Sie heraus, welche Dateien weniger als 1 Link haben (dh gelöschte, aber noch geöffnete Dateien):

lsof -nP +L1  /

Überprüfen Sie die Prozessnamen und die Pids, um festzustellen, welche Prozesse in diese "Geister" -Dateien schreiben, und handeln Sie entsprechend (einige können Sie möglicherweise stoppen / starten, und wenn sie gestoppt werden, wird die Datei freigegeben und ihr Speicherplatz freigegeben. andere erfordern möglicherweise einen ordnungsgemäßen Neustart)