it-swarm.com.de

Wer füllt meine Festplatte?

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

[email protected]:/# 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
[email protected]:/#

/ dev/sda1 ist meine primäre Festplatte, auf der Ubuntu installiert ist:

[email protected]:/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

[email protected]:/home/fmf#

Ich 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:

[email protected]:/# 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
[email protected]:/#

Anscheinend ist keine Datei oder kein Verzeichnis so groß, dass sie das 84G meiner Festplatte füllen könnten.

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

Hilfe, bitte?

9
effemmeffe

Das Problem bei Ihrem Cronjob ist, dass .xsession_errors höchstwahrscheinlich immer noch von einigen Anwendungen oder Systemdiensten geöffnet wird. Aus diesem Grund wird es beim Löschen aus der Dateisystemtabelle ausgeblendet, befindet sich jedoch immer noch auf der Festplatte und es werden weiterhin Fehler geschrieben es.
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 den Fehlern zu suchen. Dies ist die einzige Möglichkeit, dieses Problem ordnungsgemäß zu beheben.

Als Problemumgehung können Sie die .xsession_errors -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 in .xsession_errors erzeugen.

Wer füllt meine Festplatte?

seit du das tust ...

Ich stellte fest, dass dies ein bekannter Fehler in Ubuntu ist und löste das Problem, indem ich eine Crontab-Zeile erstellte, die alle zehn Minuten .xsession-Fehler löschte

es ist unmöglich, diese Frage zu beantworten.

Bitte befolgen Sie die folgenden Anweisungen, um die Fehler anzuzeigen, die wir benötigen:

  • Entfernen Sie die Crontab-Zeile, die Sie hinzugefügt haben und die .xsessions_errors entfernt.
  • Starten Sie den Computer neu und überprüfen Sie über die Befehlszeile, was .xsessions_errors mit tail -f 100 ~/.xsessions_errors füllt.
  • Wenn Sie Probleme finden, die sich häufig wiederholen, kopieren Sie einige davon in Ihre Frage.
  • Fügen Sie die Crontab-Linie wieder hinzu, damit Sie Ihr System verwenden können.
  • Warten Sie, bis das Problem behoben ist, und wenden Sie dann an. Entfernen Sie dann die Crontab-Zeile erneut (das Löschen der .xsessions_errors -Datei sollte immer vermieden werden).
10
Rinzwind

Wenn es große Unterschiede gibt (sagen wir mehr als ein paar Prozent) zwischen (als root) df -g /some/partition_root und du -gx /some/partition_root (-x fordert du auf, sich auf dieselbe Partition zu beschränken, was nützlich ist, um dies zu überprüfen '/' zum Beispiel): Möglicherweise sind noch Dateien geöffnet, in die 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 sich füllt) Der Speicherplatz (df -g sieht das), aber da es keine Links (oder Dateinamen) mehr zu seinen Inodes gibt, vermisst du -gx sie.

Vergleichen Sie in Ihrem Fall die Ausgaben von:

df -g /
du -gx /

So finden Sie heraus, welche Dateien weniger als 1 Links enthalten (dh gelöschte Dateien, die noch geöffnet sind):

lsof -nP +L1  /

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

3
Olivier Dulac