staging.inyokaproject.org

Hallo, ja es ist so, dass ich auf meiner Server ein ftp und ein ssh- client und nextcloud laufen lasse.
Jetzt ist es aber leider so, dass ich mich seit des letzten Nextcloudupdates nicht mehr auf der nextcloudwebsite anmelden kann wenn der server einige tage läuft. Ich erhalte keine Fehlermeldung sondern die Anmeldeseite wird einfach neu geladen und eine logdatei gibt es auch nicht (loglevel 2).
Jetzt habe ich mir (warum auch immer) mal die Festplattenauslatung angeschaut und naja ... die ist Randvoll (ca.235 GB), obwohl ich halt nur die paar Programme installiert habe ... ich schätze mal das ist auch der Grund weshalb Nextcloud nicht mehr läuft... (kann das sein? hat da jemand Erfahrung mit?)
Wie dem auch sei ich habe jetzt mit du -h mal geschaut wie es auf der Partition aussieht. Wobei das nicht so ganz leicht war, da ich nicht genau weiß, wie ich eine Partition analysieren lassen kann ... ich habe mir mit cd TAB TAB einfach alle Unterverzeichnisse der nächsten Ebene anzeigen lassen, in die navigiert und dort dann den Befehl ausgeführt ... geht vermutlich besser aber bei dem, was da raus kam dürften nicht mal ganz 5 GB belegt sein ... und auch das installationsverzeichnis von nextcloud war nicht übermäßig voll (ca 1,5 GB)
Weiß also jemand wie ich herausfinden kann wo der Speicherplatz hin ist? Und dann bräuchte ich (vielleicht/wahrscheinlich) noch hilfe, wie ich das verhindern kann - der Speicherplatz wird ja definitiv nicht durch von mir vorgenommene Änderungen/Installationen/Dateien belegt ... :/

Anmerkung: Ich hatte das Problem schonmal, bin aber nicht drauf gekommen, die Fesplattenbelegung zu überprüfen. dabei ist mir aber aufgefallen, dass ich mich nicht mehr per ssh auf den Server aufschalten kann, nachdem ich ihn neu gestartet habe. Er musste dann immer von Hand neu gestartet werde und dann ging es auch wieder einige Tage ganz gut (ich schätze mal bis die Platte wieder "voll" war ...)
Nuestarts und Installationen von Programmen sind also schwierig für mich, da der Server für mich physisch nicht erreichbar ist und die Platte eben angeblich voll ist...

Dateisystem      1K-Blöcke   Benutzt  Verfügbar Verw% Eingehängt auf
udev               3995728         0    3995728    0% /dev
tmpfs               803188     50556     752632    7% /run
/dev/sda2        297372400 282339400          0  100% /
tmpfs              4015932         0    4015932    0% /dev/shm
tmpfs                 5120         0       5120    0% /run/lock
tmpfs              4015932         0    4015932    0% /sys/fs/cgroup
/dev/sda1           523248      4656     518592    1% /boot/efi
/dev/md0         770840512     70368  731590676    1% /Backup
/dev/md1       10850918264 722982332 9581058188    8% /NAS
tmpfs               803188         0     803188    0% /run/user/1000
tmpfs               803188         0     803188    0% /run/user/1002

Probiere doch als erstes mal ein

sudo apt-get clean

ob das durchläuft.

Läuft durch, bringt aber keine Veränderung

Deine Ausgabe oben scheint mir vom Befehl "df -h" zu kommen. Zeig doch noch mal

sudo du -sh /*

Gründe könnten z.B. sehr große Logdateinen sein (/var/log/... ?). Falls Daten auf einer extra Partition abgelegt werden sollen und diese nicht eingehängt ist, wird direkt auf den Einhängepunkt der Platte geschrieben. Auch ein "beliebter" Fehler, der sehr schnell eine Partition füllen kann.

Oder nimm das Tool ncdu, damit bekommst Du schön schnell eine Übersicht, wo der Platz denn verbraucht wird, indem Du einfach folgendes eingibst:

ncdu /

Das ist die Ausgabe:

20K	/Backup
16M	/bin
68M	/boot
0	/dev
7,3M	/etc
4,0K	/home
0	/initrd.img
455M	/lib
4,0K	/lib64
16K	/lost+found
16K	/media
4,0K	/mnt
690G	/NAS
4,0K	/opt
0	/proc
124K	/root
50M	/run
13M	/sbin
4,0K	/snap
8,0K	/srv
0	/sys
48K	/tmp
952M	/usr
1,5G	/var
0	/vmlinuz

und externe Fesplatten sind nicht am system ... außer halt die verzeichnisse NAS und Backup aber das sind fest verbaute Platten und wenn das nicht klappen würde, würden die ja einfach nicht angezeigt werden ... das läuft ja ... und in den Verzeichnissen kann ich über sftp auch problemlos Dateien erstellen ...

Zeige mal bitte die Ausgabe von folgendem Kommando:

sudo lsof +L1 2>/dev/null| tail -n +2 |sort -k 10,10 | uniq -f 9| awk '{sum +=$7} END {OFMT = "%.0f"; print sum}'

Ja, für einen ersten Überblick ist df -h bzw. du -h besser geeignet, damit man nicht die Nullen zählen muss.

Ich habe bei der Suche nach Dateimonstern folgendes Suchmuster entwickelt:

Starte nicht im Wurzelverzeichnis, aber in den verdächtigen Verzeichnissen der Ebene darunter, und mach eine erste Inspektion, ob es da viel Belegung gibt. /usr zum Beispiel würde ich erst betreten, wenn in den anderen Verzeichnissen nix war. /proc kann man auslassen, /etc wahrscheinlich usw.

Wegen der logdateien ist /var ein beliebtes Ausflugsziel.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

cd /var
du -s * 2>/dev/null | sort -n 
0	lock
0	run
4	local
4	mail
4	metrics
4	opt
4	snap
124	spool
240	tmp
2580	crash
7836	backups
39264	log
399708	lib
686628	cache

Fehlermeldungen habe ich unterdrückt, weil ich mich nicht als root anmelden wollte, nur für Demozwecke, aber mit sudo braucht man das natürlich nicht.

Hier sieht man jetzt, dass cache der Hauptverbrecher ist, wechselt da rein, und wiederholt das Verfahren.

1

cd cache;  du -s * 2>/dev/null | sort -n 

Und so steigt man tiefer und tiefer bis man findet, sonst sucht man woanders.

Das Caching kommt einem dabei zu Hilfe. Dass die Information aus den Unterverzeichnissen schon vorliegt scheint sich der Rechner zu merken.

Ich tippe auf /var/log - irgendwer der 4x pro Sekunde meldet, dass er einen Font nicht findet oder sowas. ☺

Aber werden denn die Inhalte der Unterverzeichnisse bei der Ausgabe von ncdu / nicht berücksichtigt? Da wäre ja beispielsweise der Ordner var 1,5 GB groß...

Newbunto schrieb:

außer halt die verzeichnisse NAS und Backup aber das sind fest verbaute Platten und wenn das nicht klappen würde, würden die ja einfach nicht angezeigt werden ... das läuft ja ... und in den Verzeichnissen kann ich über sftp auch problemlos Dateien erstellen ...

Nee, nicht unbedingt. Wenn die Platten physikalisch vorhanden sind aber durch einen Fehler nicht richtig eingehängt werden, wird direkt in das Verzeichnis geschrieben, in das sie in den Verzeichnis eingehängt werden sollten. Das kann z.B. "/mnt/IRGENDEINNANE" sein. Ansonsten funktionier dann alles prima und man merkt nichts, bis die Partition voll ist. NAS scheint mir unverdächtig aber wo wird bei Dir Backup eingehängt?

Was sagt

sudo mount

?

Newbunto schrieb:

Aber werden denn ...

Evtl. auch mit:

find / -type d -exec du -sh {} \; 2>/dev/null | sort -brh | head -n 30

mal testen.

Naja, in der obigen Ausgabe von

du -sh /*

sieht man ja nicht, wo der Platz denn nun abbleibt. Abgesehen von /NAS ist da ja kaum etwas verbraucht. Bei ncdu werden die Unterverzeichnisse auf jeden Fall mit berücksichtigt. Das macht es ja so schön einfach.

Aber vielleicht hast Du viele Dateien, die eigentlich gelöscht sind, sich aber noch im Zugriff befinden. Diese werden dann von du nicht mit angezeigt, aber bei df wird der belegte Platz dann durchaus mit berücksichtigt. Daher poste doch mal bitte die Zahl, die bei diesem Kommando rauskommt:

sudo lsof +L1 2>/dev/null| tail -n +2 |sort -k 10,10 | uniq -f 9| awk '{sum +=$7} END {OFMT = "%.0f"; print sum}'

Der Befehl zeigt einfach an, wieviel Platz belegt wird, die eigentlich gelöscht sind, sich aber noch im Zugriff befinden und daher nicht gelöscht werden können...

Ich würde anfangen mit

1

du -xmd 2 / | less

Das schaut nur in das Root-Dateisystem (Option -x), was ja nach dem Eingangsposting das volle ist, und macht nur Ausgaben für die ersten beiden Ebenen. Außerdem habe ich -m genommen, damit alle Zahlen in der selben Einheit ausgegeben werden; das erleichtert deutlich das visuelle Finden der vollen Verzeichnisse. Dann kann man schauen, wo man weiter abtaucht.

Man kann sich auch recht leicht Prozentwerte ausgeben lassen:

1

du -xmd 2 / | awk '{s[NR] = $1; l[NR] = $0} $1 > max {max = $1} END {for (i=1;i<=NR;++i) printf "%6.2f%%  %s\n", 100.0*s[i]/max, l[i]}' | less

Laut der obigen Tabelle ist /backup fast leer (70MB Backups ?). Ungewöhnlich für ne backup Platte. Eventuell hat er alles direkt in /backup auf die Hauptplatte geschrieben weil die externe Platte zu dem Zeitpunkt nicht gemountet war? Mal backup Platte unmounten und dann backup ansehen.

Newbunto schrieb:

Ich mache es in solchen Fällen so, falls man sich mal wieder mit ssh anmelden kann:

1

du -hd1 .

von Hand in das 'verdächtige' Directory wechseln und wiederholen.

Damit man am schnellsten den 'Verdächtigen' und kann das Problem eingrenzen, bevor man wieder raus fliegt.

Alles andere halte ich für zu kompliziert.

du -sh wird oft mal verwendet und -d gibt die Rekursionstiefe an.

Damit ist man vertraut und man braucht sich fast nichts zu merken. Komplexere Kommandos machen Sinn, wenn man diese in ein Skript schreibt und damit ohne grosse Gedächtnisübung zur Verfügung hat.

Will man mehr wissen, hilft, im 'current directory', sonst dauert das zu lange:

1

find . -type f -printf '%TY-%Tm-%Td %TH:%TM: %p\n'| sort -n | tail -n20

Find zeigt damit die zuletzt geänderten Files mit lesbarem Datum an. Meist ist der 'Übeltäter' dann schon lokalisiert.

So ganz wird das nicht helfen. Wenn nach einem Neustart ssh nicht mehr funktioniert, aber nach einem Neustart 'per Hand' (wo ist der Unterschied?) alles wieder einige Zeit ok ist, ist noch was anderes faul.

Gruß

rleofield