SD Karte wird von irgend Etwas zugemüllt

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    vor ca. einen Monat war meine SD im RP2, den ich als Webserver und Datenloger seit ca 2 Jahren nutze, voll.

    Darauf habe ich die Daten der 8GB SD auf eine 32GB SD kopiert und alles war wieder gut.

    Heute waren dann auch die 32GB voll.

    Wo fange ich an?

    Ich bin kein Linux-Experte!

    LG

    Daneie

  • Wenn auf dem Pi wirklich nichts anderes läuft würde ich einfach mal die Logdateien vom Webserver überprüfen - evtl. hast du fehlerhaften Code.

    => /var/log/apache2/

    Wenn sich da nichts auffälliges finden lässt könntest du als nächstes prüfen welches Wurzelverzeichnis auf der SD Karte am meisten Platz verballert:

    => du -sh /*

    (ausgabe bitte in CODE posten)

  • Hallo meigrafd,

    danke für deine Antwort.

    Ich muss noch dazu sagen, dass ich aktuell die 8GB SD wieder auf die 32GB kopiert. So läuft der RP wieder.

    Ich habe in var/log/ 3 große Dateien ausgemacht

    kern.log

    messages

    syslog

    alle 3 ca 784 MB groß

    Hier ein Teil von syslog

    < sudo dumpe2fs -h /dev/sda2 >, wobei /dev/sda2 mit Deiner tatsächlichen root Partition zu ersetzen ist.

    Hallo RTFM,

    wie schon gesagt ich bin kein Linux-Experte!

    Muss jetzt Schluss machen.

    Bis morgen!

  • /var/ ist 2,6GB groß... das ist etwas zu viel :shy:

    Was genau verstehst du unter "Datenloger" ?

    Und was für ein Webserver läuft bzw was läuft darüber?

    Was ist an den Pi angeschlossen? Bitte ALLES nennen.

    Welches OS benutzt du?

    Poste mal bitte noch die Ausgabe von: du -sh /var/log/*

  • Hallo,

    mein Betriebssytem ist Raspbian Jessie.

    Installiert ist lighttpd, php, SQLite

    Über je eine serielle Schnittstelle empfange ich Daten von der Heizungssteuerung

    und der Bewässerungssteuerung (C-Control AVR32).

    Mit der IIC wird der Grundwasserstand abgefragt (Arduino Uno als Slave)

    Gesteuert wird das Ganze mit Phython und in eine Datenbank geschrieben.

    Auf einer RAM-Disk werden die aktuellen Werte für die PHP-Abfrage zur Verfügung gestellt.

  • Die 3 Dateien sind wohl die Ursache für deine volle SD, die logs werden zugespamt.

    Das Problem mit dem action 'action 17' suspended, next retry is hatte ich unter Jessie auch schon.

    Da gabs Abhilfe:

    https://blog.dantup.com/2016/04/removi…aspbian-jessie/

    Bei den anderen Meldungen hilft es vllt. den Loglevel zu verändern.

    Oder einfach mal das System aktualisieren.

    Wenn sonst nichts in den Logs steht, einfach mal die .gz und .1 löschen, damit wieder Platz ist, aber besser man vermeidet unnötige Schreiberei auf der SD.

    P.S. Hast du die serielle Console in der /boot/config.txt ausgeschaltet ?

    Sieht so aus als würde der sysrq von den Daten der Heizungssteuerung und der Bewässerungssteuerung getriggert.

    https://wiki.ubuntuusers.de/Magic_SysRQ/

  • Heißt das ich kann alles im Ordner log mit diesen Endungen ohne Bedenken löschen?

    Ja, wenn Du löschen darfst/kannst.

    Rein rechnerisch ist mit Deinem Datenbestand eine volle 32 GB SD nicht erklärbar.

    Entweder wurde die root Partition nicht auf die 32 GB Grenze ausgedehnt, oder das EXT4 Filesystem frisst (unsichtbar) Inodes und/oder Sektoren, weil das Filesystem nicht "clean" ist.

    Da brauchst Du kein Linux-Experte zu sein um ein " l i s t b l o c k d e v i c e s " durchzuführen um die root Partition ("/") zu erkennen.

    Wenn die Anzeige von < lsblk > noch zu dubios ist, mach ein < lsblk -f > (F, wie Filesystem) und suche nacht EXT4 und "/".

    Für weitere Details siehe < lsblk -h >, H, wie help, oder < man lsblk >, oder < info lsblk >.

    Den gefundenen (Partitions-)Name trägst Du dann mit /dev/DeinRootPartitionsname

    .. und führst < sudo dumpe2fs -h /dev/sda2 > aus.

    Dann siehst Du u.A., ob der Filesystemstatus "clean" ist und wieviele Sektoren und Inodes schon verbraucht sind.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • oder man führt einfach

    df -i / /var

    aus

    ergibt

    Code
    pi@webpi2:~ $ df -i / /var
    Dateisystem     Inodes IBenutzt   IFrei IUse% Eingehängt auf
    /dev/root      1911616   101902 1809714    6% /
    /dev/root      1911616   101902 1809714    6% /

    Ich bräuchte eine Erklärung zum Ergebnis.

  • Heute waren dann auch die 32GB voll.

    BTW: Mit z. B.:

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

    kannst sortiert, die 10 Verzeichnisse (inkl. Pfad) anzeigen lassen.

    Z. B. auf meinem PI:

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ich bräuchte eine Erklärung zum Ergebnis.

    d.h. dass dein /var (hätte /var/log sein sollen) auf dem root-fs liegt und bei diesem nur 6% der verfügbaren Inodes in Benutzung sind. Also alles OK.

    Benutze bitte das von rpi444 vorgeschlagene find-Kommando und führe anschliessend nochmal das "df -i ...." mit dem grössten Verzeichnis als Parameter aus.

    Vereinfacht:

    Jede Datei/jedes Verzeichnis (Sonderform einer Datei) bzw. dessen Namenseintrag belegt einen Inode. Die Anzahl der Inodes im Dateisystem wurde beim Anlegen festgelegt. Sind die verfügbaren Inodes "verbraucht", kannst du keine Dateien mehr anlegen, egal wieviel Speicherplatz theoretisch noch zur Verfügung steht. Dieser Fehler tritt allerdings sehr selten auf (idR Dateisysteme mit extrem vielen kleinen Dateien).

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. April 2018 um 08:36)

  • Ich bräuchte eine Erklärung zum Ergebnis.

    Der Filesystem - Status ist hier nicht ersichtlich.

    Der ist im Header des Ext4-Superblocks abgelegt.

    Bei mir z.B.:

    Code
    Filesystem state:         clean
    Errors behavior:          Continue
    Filesystem OS type:       Linux
    Inode count:              1831424
    Block count:              7323904
    Reserved block count:     366195
    Free blocks:              5241461
    Free inodes:              1450022

    Solange Error behavior auf Continue eingestellt ist und der Filesystem state nicht auf clean steht, wird vom Journal bei jedem Schreib-/Löschzugriff mindestens ein Inode (unsichtbar) verbraucht, sobald die eingestellte Journalgrösse überschritten wird.


    Und ja, es gibt auch andere Befehle, den Superblockheader auszugeben.

    Servus !

    RTFM = Read The Factory Manual, oder so

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!