Backupskript verursacht Systemfehler (stack limit)

  • Hallo zusammen,

    über folgendes merkwürdiges Problem möchte ich heute berichten und fragen, ob jemand ähnliche Erfahrungen schon damit gemacht hat, oder das Problem des Fehlers sieht.

    framp, ja schande über mich dass hier noch nicht raspibackup zum Einsatz kommt - tauchten bei raspibackup auch schon solche Fehlerberichte auf?


    Ausgangssituation:

    Zum sichern der kompletten SD Karte auf ein NAS kommt folgendes sh Skript monatlich via root Crontab zum Einsatz:

    crontab:00 05 * * 7 [ $(date +\%d) -le 07 ] && /bin/sh /opt/redmine/script/backup_sdcard.sh

    backup_sdcard.sh:

    Dies erledigte auch schon seit 2 Jahren zuverlässig seinen Dienst (vor ca. einem Jahr wurde mit Hilfe des Forums heir der Part ergänzt im crontab [ $(date +\%d) -le 07 ]).

    Jetzt in diesem April wurde jedoch der vorhanden Raspberry Pi durch einen Raspberry Pi 3 B+ ersetzt. Folglich ist jetzt auch statt Jessi Stretch im Einsatz.

    Code
    PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="9"
    VERSION="9 (stretch)"
    ID=raspbian
    ID_LIKE=debian
    HOME_URL="http://www.raspbian.org/"
    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
    Code
    Linux raspberrypi 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l GNU/Linux


    Das nun am Sonntag per cron gestartete Backup war auffällig klein (560 MB statt 4GB) und auch der Pi ließ sich nicht mehr anpingen.

    Somit hab ich das Skript jetzt manuell gestartet, (2x) die jeweilige Fehlermeldungen:

    Das NAS ist erreichbar, auch kam der Fehler nicht immer bei der selben Speichergröße des Backups.


    Worauf kann man nun den Fehler zurückführen? Bug im OS? :evil:


    EDIT: Der Pi ist anschließend nach Ausgabe der Fehlermeldungen nicht mehr zu erreichen, weder per SSH noch lässt er sich anpingen.

  • Wie schnell nach dem Starten des Skripts treten denn die Fehlermeldungen auf?


    Ist die SD-Karte im 3+ deutlich höher belegt als im 3?


    Wie sieht /proc/meminfo aus?


    Hängt vermutlich nicht damit zusammen, aber gibt es einen bestimmten Grund, warum Du das Skript per gültigem shebang als bash-Skript schreibst, es dann aber per /bin/sh aufrufst?

  • Wie sieht /proc/meminfo aus?

    Während des Backup Vorganges oder im normalen Betrieb?

    Normaler Betrieb:


    Ist die SD-Karte im 3+ deutlich höher belegt als im 3?

    Dienste und Anwendungen sind identisch, Backup vergleich mit dd hab ich durch den Fehler leider keinen Vorliegen.

    SD Karten Gesamtgröße kam bei beiden eine 16GB Karte zum Einsatz. sanDisk in beiden Fällen.


    Nach ca. 6 Minuten kommt es zu dem Fehler.


    EDIT: nein kein Grund, hierbei handelt es sich lediglich um einen Fehler meinerseits mit dem Unterschied von bash zu sh im Shebang

  • Message from syslogd@raspberrypi at May 7 17:02:40 ... Message from syslogd@raspberrypi at May 7 17:35:50 ...

    framp, ja schande über mich dass hier noch nicht raspibackup zum Einsatz kommt - tauchten bei raspibackup auch schon solche Fehlerberichte auf?

    Bislang gab es keinen ähnlichen Bericht. raspiBackup läuft problemlos unter Stretch. Falls es mit der Raspi 3 B+ zu tun hat: Ich habe keine und weiss auch nicht ob schon jemand jemals raspiBackup auf einer Raspi 3 B+ mit Stretch laufen liess.


    Bekommst Du den Fehler auch wenn Du den dd Befehl alleine eingibst? Vermutlich ja. Mir sieht das irgendwie nach einem OS Problem mit der Raspi 3 B+ aus.

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect."

    Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert =O Bei mir tut das raspiBackup automatisch ;)

  • Während des Backup Vorganges oder im normalen Betrieb?

    Sowohl als auch. Schau doch mal während eines Backupvorgangs mit top, ob die Speicherbelegung vor dem Auftreten des Fehlers massiv zunimmt.

    Dienste und Anwendungen sind identisch, Backup vergleich mit dd hab ich durch den Fehler leider keinen Vorliegen.

    Was sagt denn df -h /? Und weisst Du noch, wie das auf dem 3er aussah?


    Versuch doch mal, das Skript ohne gzip laufen zu lassen – bekommst Du da den gleichen Fehler?

  • df -h /:

    Code
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/root        15G  6.2G  7.8G  45% /

    Ich hätte noch einen Backupstand mit Pi3 und Jessie...da ich aber eine direkte Neuinstallation vorgenommen habe lässt sich dies eh nicht 100% vergleichen...was ich jetzt jedoch als nächste Versuche ist, ich nimm den Pi3 und steck da die SD Karte von Pi3B+ rein und versuche ob dass funktioniert:


    ....wenige :lol: Minuten später ....


    siehe da, mit dem Raspberry Pi 3 funktioniert die Ausführung des Backup Skriptes mit der SD Karte vom B+ ohne Probleme.


    Soll ich dennoch eure oben genannten Schritte durchführen? Für mich zeigt sich auf alle Fälle schonmal das hier ein Problem mit dem B+ in Kombination mit dem aktuellen OS besteht?! Oder sehe ich da was falsch?


    Bitte wenn jemand einen B+ und eine NAS hat, oben gennantes Skript bitte mal ausführen zur Gegenkontrolle.

  • Message from syslogd@raspberrypi at May 7 17:35:50 ...
    :

    Message from syslogd@raspberrypi at May 7 17:35:50 ...
    :
    Message from syslogd@raspberrypi at May 7 17:35:50 ...

    Das erste, was ich tun würde, wäre das völlig überflüssige rsyslog zu entfernen... das ist unnötig, überflüssig, befriedigt nur die ewig-gestrigen.. :evil:


    Du weisst, dass rsyslog heute keine "echte" Funktion mehr hat und auch keine "echten" primären Daten bekommt, sondern nur das, was systemd-journald an rsyslog weiterreicht? Du weisst, dass das, was in rsyslog steht, nix anderes als ne irrsinnige Doppelspeicherung ist und alle Inhalte sowieso vollständig in journald zu finden sind? Und Du weisst, wenn Du das Schreiben von journald von der SDC weggelagert hast, dass rsyslog möglicherweise immer noch fleissig und ungehemmt trotzdem die SDC schreibt?


    Also ich würde ja als allererstes rsyslog purgen... und dann mal schauen, was draus wird... das Script sieht m.M.n. doch wirklich nicht ungewöhlich oder exotisch aus... und sollte auch so funktionieren.


    jm2c

  • Bekommst Du den Fehler auch wenn Du den dd Befehl alleine eingibst? Vermutlich ja.

    Deine Vermutung ist richtig:

    Zuvor habe ich noch per Hand mit systemctl alle Dienste wie im Skript auch beendet.


    Versuch doch mal, das Skript ohne gzip laufen zu lassen – bekommst Du da den gleichen Fehler?

    Da dd schon zu einem Fehler führt wirds wohl im Skript auch so sein, ansonsten hätt ich natürlich auch deinen Vorschlag durchgeführt.


    Du weisst, dass rsyslog heute keine "echte" Funktion mehr hat und auch keine "echten" primären Daten bekommt,

    Ehrlich gesagt nein, mit den ganzen Logfunktionen bin ich noch ziemlich schwach und dieses wohl sehr wichtige Gebiet wurde von mir noch zu sehr außer Acht gelassen, was ich aber definitiv nicht so belassen möchte.

    In diesem Fall wird aber rsyslog nicht der Schuldige sein, da ja die alleinige Ausführung von dd schon zu einem Fehler führt.

    Aber dennoch bedanke ich mich für deinen Hinweis und werde das im Hinterkopf behalten, denn wie auch der andere Thread zeigte zeige ich mich durchaus offen gegenüber Systemd und nein will ich nicht dazugehörten ;):

    befriedigt nur die ewig-gestrigen.. :evil:


    Schade dass sich keiner finden lässt mit einen Raspberry Pi 3 B+ in einem Raspberry Pi Forum, der den Versuch wiederholen könnte

    *in die Runde blick*

  • Servus Hofei ,

    welche Eckdaten?

    Also: welches FS auf dem Backup-Medium, wie gross (das Backup-Medium), wieviele Daten sichern?

    Ist eine ssh-Verbindung aktiv?


    Kann ich gerne mal testen. Hab' den (einzigen) Plus mal aus seiner Schlafkabine geholt und gestartet ...

    cu,

    -ds-

    • Official Post

    was systemd-journald an rsyslog weiterreicht?

    Dann sollte es ja kein Problem sein in dem deutlich modernerem, besserem System einen Lösungsansatz zu finden. Aber nö - rsyslog is doof, dabei bietet journald auch keine Hilfe - warum purgen wir nicht das? :shy:.


    Ich muss mir dringend mal nen neuen Pi besorgen

  • Hallo,

    als Backupmedium dient eine im lokalen Netzwerk erreichbare NAS von Qnap: TS-251


    Auf den eingerichteten FreigabeOrdner wird mittels Samba zugegriffen (hierbei hab ich auch keinen Einfluss dass es da bessere Möglichkeiten gäbe ;) ).

    FS von der NAS ist ext4.

    Code
    //192.168.26.250/Redmine_Backup/ /media/NAS/ cifs credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,dir_mode=0700,file_mode=0600,nounix,x-systemd.requires=network-online.target    0    0

    Gesichert wird im Grunde ein frisch aufgespieltes Raspbian Stretch mit zusätzlich installiertem Redmine.

    Da wären hier die mitschriften, da wollte ich mal ein Tutorial erstellen (Auskommentiertes wurde noch vollzogen)

    Als ich mit dem Raspberry Pi 3 das Backup erstellt habe, wurde die Backupdatei 2,74 GB groß.

    wieviele Daten sichern?

    Der dd Befehl sichert die komplette SD Karte welche eine größe von 16GB aufweist.

    Erstmalig als der Fehler auffiel war keien SSH Verbindung aktiv, da wurde das Skript durch cron gestartet, aber auch mit SSH per Hand ausgeführten Befehl tritt der Fehler auf.


    Vielen Dank für dein Mitwirken^^


    dbv ja als Administrator des Pi Forums muss man auch jedliche verfügbare Hardware dieses Themas besitzen :)

  • Ach noch was ...

    Läuft die grafische Oberfläche?

    Ist das OS per update/upgrade (evtl. sogar rpi-update) nachgezogen worden oder ist die Grundlage ein stretch-Image (lite/full?) von der Foundation?


    Hast Du das mal mit of=/dev/null probiert?

    btw: das ist kein Fehler bezüglich stack-limit ;)

    Das ist nur eine informelle Ausgabe wie die pid, anschliessend folgt der stack trace für den angegebenen Bereich.

    Oops verzweigt i.d.R. in den kdb ... tut es bei Dir aber nicht.

    Ich tippe auf eine race-condition oder so was ... ein genauer Grund wird leider nicht geliefert.

    Du könntest das jetztim gdb laufen lassen ... aber ich trau' mich fast wetten, dass dann der Fehler nicht auftritt.

    strace wäre evtl. noch eine Massnahme ...


    cu,

    -ds-

  • Was passiert denn bei

    Code
    dd if=/dev/zero of=/dev/null count=200000
    dd if=/dev/zero of=/dev/null bs=1M count=1000
    dd if=/dev/zero of=/media/NAS/SD-Card/testbackup.img count=200000
    dd if=/dev/mmcblk0 of=/dev/null

    dreamshader: Sorry, Du hast gepostet, während ich getippt habe.

    Hofei: Die counts evtl. vergößern, so daß der dd mindestens so lange läuft, wie's üblicherweise zum Absturz braucht.

  • (evtl. sogar rpi-update)

    :conf::dau2: (nein)

    Ist ein frisches Fullimage vom 18.04.2018

    Anschließend wurde natürlich ein update/upgrade ausgeführt, rpi-update dagegen nicht.


    Also ich hab das Bootverhalten nicht geändert, somit denke ich bootet er die GUI auch noch, was ziemlich unnötig ist, jetzt wo wir darüber schreiben. Aber für die weiteren Testzwecke werd ich an dieser ("Standart")Einstellung nichts verändern.


    Zugegeben ab deinen 2. Absatz versteh ich nicht mehr recht viel, außer dass ich dd ausführen soll:

    Code
    pi@raspberrypi:~ $ sudo su
    root@raspberrypi:/home/pi# dd if=/dev/mmcblk0 of=/dev/null
    31116288+0 records in
    31116288+0 records out
    15931539456 bytes (16 GB, 15 GiB) copied, 694.888 s, 22.9 MB/s
    Code
    root@raspberrypi:/home/pi# dd if=/dev/zero of=/dev/null count=8000000
    8000000+0 records in
    8000000+0 records out
    4096000000 bytes (4.1 GB, 3.8 GiB) copied, 13.1966 s, 310 MB/s

    Und hier ist der Bösewicht:

    üblicherweise zum Absturz braucht.

    Also beim letzten Test in #8 kam der Fehler schon nach ca. 1 Minute^^

  • Das passt schon mit of=/dev/null ... da scheint der dd dann zu funktionieren.

    Demzufolge wird der Fehler durch die Verbindung vom NAS erzeugt.

    Ich setz' mal die 16er Karte auf ... wobei: ich kann leider weder mit NAS noch mit samba dienen.

    Ich probier's halt mal über USB auf eine andere SD ...


    cu,

    -ds-

  • als Backupmedium dient eine im lokalen Netzwerk erreichbare NAS von Qnap: TS-251


    Auf den eingerichteten FreigabeOrdner wird mittels Samba zugegriffen (hierbei hab ich auch keinen Einfluss dass es da bessere Möglichkeiten gäbe ;) ).


    FS von der NAS ist ext4.

    Code
    //192.168.26.250/Redmine_Backup/ /media/NAS/ cifs credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,dir_mode=0700,file_mode=0600,nounix,x-systemd.requires=network-online.target    0    0


    Das "lustige" ist ja, ich muss nur die SD Karte nehmen und in einen RPi 3 stecken ohne + (+ bedeutet wohl viel Ärger) und alles funktioniert wie gehabt. Die Probleme entstehen nur mit der Hardware 3B+

  • Danke. Ich hatte die Seite nach "Dateisystem" und "Filesystem" durchsucht, da ist mir das "FS" durch die Lappen gegangen.

    Auf den eingerichteten FreigabeOrdner wird mittels Samba zugegriffen (hierbei hab ich auch keinen Einfluss dass es da bessere Möglichkeiten gäbe ;) ).

    Warum nicht? Gibt's echt eine NAS, die kein NFS kann?


    Alles inklusive NAS durchgebootet hast Du vermutlich schon?


    Nachtrag: Hast Du's mal mit einem anderen Linux auf dem 3+ versucht?