Backupskript verursacht Systemfehler (stack limit)

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Also ... ich kann das, wie bereits vermutet, nicht reproduzieren.

    Ich lehne mich jetzt mal weit aus dem Fenster und behaupte, das ist entweder eine race condition oder ein bug in samba.

    Der 3B+ ist halt nen Ticken schneller als der Pi 3B ...

    Hast Du mal versucht die Verbindung mit dem samba share mal mit ein paar grösseren, parallelen Kopiervorgängen zu quälen?

    Ich würde auch mal nachsehen, ob der NAS nicht nfs kann, so wie Manul auch schon angemerkt hatte.

    Das mit strace resp. gdb hatte ich nur mal so hingeschmissen ... wenn Du das script in strace laufen lässt (Optionen musst Du gucken, weiss ich nicht mehr auswendig) siehst Du alle systemcalls und kannst näher eingrenzen wo die Schweinebacke abkackt.

    Hast Du mal eine Weile gewartet, nachdem das script abgestürzt ist, bevor Du den pi anpingst oder versuchst per ssh zu erreichen?

    Kann sein, dass die "kaputte" Verbindung die Netzwerk-Schnittstelle zumüllt ... möglicherweise ist der Pi nach dem durchschnittlichen TCP/IP Timeout ( sind, afair so ca. 15 Minuten ) wieder normal erreichbar ist.

    //EDIT: Du könntest mal mit der blocksize experimentieren (bs=32M oder 64M ...).

    Das ist zwar dann keine echte Lösung, aber evtl. wird das Laufzeitverhalten da so beeinflusst, dass es wieder funktioniert ;)

    cu,

    -ds-

  • Backupskript verursacht Systemfehler (stack limit)? Schau mal ob du hier fündig wirst!

  • Das bzgl NFS war unglücklich ausgedrückt, ich meinte, ich persönlich wüsste dass es andere Möglichkeiten gibt als Samba, aber die NAS wird nur zur Verfügung gestellt, und dort ist Samba eben aktiv.

    In der Zwischenzeit habe ich jetzt dennoch Testweise NFS aktiviert, konnte auch schreiben (länger als bei Samba) hier kommen auch keine Fehlermeldungen, aber irgendwann hört er auf mit dem Image schreiben und der Pi hängt sich auch auf. (siehe Bild) Befehle wie ls o.ö werden ebenfalls nicht ausgeführt.

    Für mich ist an dem Punkt vorerst Schluss, eine positive Erfolgsmeldung blieb zu lange aus...

    Danke an alle die hier aktiv teilgenommen haben um mich zu Unterstützen! :danke_ATDE:

  • Trotzdem irgendwie strange ...

    Da bin ich voll bei dir, und ich kanns nicht oft genug sagen, es ja mit dem Pi3 funktioniert, nur nicht mit Pi3B+

    EDIT: ich markiere jetzt trotzdem mal mit Absicht den Thread nich als erledigt, da er ja nicht gelöst ist.

    • Offizieller Beitrag

    Schade dass Du erstmal abbrechen willst, aber mir geistern noch ein paar Dinge im Kopf herum, die ich loswerden muss.

    Mich irritiert daran, dass der 3+ danach nicht mehr erreichbar ist. Das spricht imho für die "Klassiker" Netzwerk oder Netzteil. Hast Du es denn auch mal andersherum probiert, also eine große Datei vom NAS zum RPi z.B. auf eine externe HDD? (Rhetorische Frage!) ;)

  • 5,1V offizielles Netzteil

    andersherum probiert, also eine große Datei vom NAS

    jetzt gerade ja,

    Die 2,8GB große Image Datei, welche mit dem RPi 3 erstellt worden ist, lässt sich erfolgreich von NAS auf den RPi 3B+ kopieren, als auch wieder vom RPi 3B+ zur NAS kopieren, für beide Kopiervorgänge kam cp zum Einsatz.

  • root@raspberrypi:/home/pi# dd if=/dev/zero of=/media/NAS/SD-Card/testbackup.img count=200000

    root@raspberrypi:/home/pi# dd if=/dev/zero of=/media/NAS/SD-Card/testbackup.img count=200000

    Ich kann nur sagen, was ich zur Fehlersuche unternehmen würde...

    1. rsyslogd zumindest deaktivieren, weils definitiv durch die aktive Speicherverwendung einen Einfluss auf den Fehler hat

    2. auf jeden Fall mit einer vorgegebenen Blocksize testen, z.b. bs=1M

    3. und wenn ich unbedingt eine Gesamtgröße vorgeben muss, dann eben den Count-Param an der Blocksize orientieren.

    4. vor dem DD-Start ein zweites Fenster öffnen und parallel "journalctl -f" mitlaufen lassen

    Ich halte das für ein Speicherproblem, was man vermutlich mit entsprechender Handhabung/Parameter einfach lösen kann.

    dbv

    Ich habe nix gegen rsyslog... Du solltest aber akzeptieren, dass rsyslog unter systemd imho ein Koma-Patient OHNE Funktion ist... der völlig sinnlos Ressourcen verschwendet. rsyslog erhält nur noch vorverdautes und hervorgewürgtes Futter, und das soweit ich weiss ohne Garantie auf Vollständigkeit... aber da kann ich mich täuschen. Es gibt unter Stretch derzeit nur einen primären Nachrichten-Verwurster, und das ist Journald... insofern ist es dumm, noch auf rsyslog zu setzen. Wenn Du natürlich journald entfernt hast... na klar... dann gehts nicht ohne rsyslog. Aber mit Journald ist rsyslog das Fässchen Wasser, was Du schwer keuchend sinnlos den Berg rauf schleppst, um oben festzustellen, dass da ein Brunnen mit deutlich besserer Wasserqualität ist.

    • Offizieller Beitrag

    5,1V offizielles Netzteil

    Selbstverständlich setzt Du das ein, bei Dir brauche ich mir über die Grundsätze keine Gedanken zu machen! ;) Aber das ist alles wirklich seltsam...

    Nur am Rande. dd hat auch eine Fortschrittanzeige. dd if=/dev/XXX of=/dev/XXX status=progress. Könnte evtl. helfen, falls Du es weiter versuchen willst.

  • Ich habe nix gegen rsyslog... Du solltest aber akzeptieren, dass rsyslog unter systemd imho ein Koma-Patient OHNE Funktion ist... der völlig sinnlos Ressourcen verschwendet. rsyslog erhält nur noch vorverdautes und hervorgewürgtes Futter, und das soweit ich weiss ohne Garantie auf Vollständigkeit... aber da kann ich mich täuschen. Es gibt unter Stretch derzeit nur einen primären Nachrichten-Verwurster, und das ist Journald... insofern ist es dumm, noch auf rsyslog zu setzen.

    leicht OT, aber sei es drum:

    Dann schreib doch mal bitte, wie ich journald dazu bewege, die Logs auf einen remote Logger (NAS, Syno, Protokollinfos im Bild) konfigurieren muss.

    Die Frage ist übrigens ernst gemeint...

  • Dann schreib doch mal bitte, wie ich journald dazu bewege, die Logs auf einen remote Logger (NAS, Syno, Protokollinfos im Bild) konfigurieren muss.

    Das ist nicht nur völlig OT, sondern natürlich auch noch weit weg von einer normalen privaten Standard-Enduser-Installation, und diese dann auch noch auf einem PI. Aber seis drum... soweit ich weiss, ist das mit journald nicht direkt vorgesehen... insofern könnte man das natürlich mit diesem Message-Forwarding auf rsyslogd lösen.

    Ich würde allerdings versuchen, entweder eine permanente Ausgabe des Logs (gestartet über eine Service-Unit) auf einen Port zu pipen und den Port auf dem Zielsystem in ein File schreiben, oder den Stream via ncat über eine SSL-Verbindung zu senden. Gegebenenfalls, wenn das ausreichend wäre, würde ich auch nur zyklisch ein zeitlich festgelegtes Log-Paket senden. Welches die beste Lösung ist, entscheiden die betrieblichen Bedingungen, Normen, Regeln, Verträge... keine Ahnung. Aber wie gesagt, das hat hier ganz bestimmt keine Bewandnis für Hofei's Problem... und für solchen exotischen (aus Sicht privater Anwender) Anforderungen kann das redundante rsyslog auch durchaus eine Lösung sein.

  • Das ist nicht nur völlig OT, sondern natürlich auch noch weit weg von einer normalen privaten Standard-Enduser-Installation, und diese dann auch noch auf einem PI. Aber seis drum... soweit ich weiss, ist das mit journald nicht direkt vorgesehen... insofern könnte man das natürlich mit diesem Message-Forwarding auf rsyslogd lösen.

    Nein, ist es eben nicht (weder OT noch weit weg im privaten Umfeld):

    Gerade wenn ich einen headless-Pi habe und zu dessen SD-Karten Schutz u.a. das /var/log Verzeichnis nicht beschreiben will, jedoch die Logs dennoch nach einem ggf. erfolgten Power-down oder einem anderen Fehlerzustand auswerten will, nützt mir das oft beschriebene Verlegen des /var/log-Verzeichnis (oder wo immer eben auch Journald seine Logs hinschreibt) in den RAM nichts, weil die dann weg sind.

    GENAU DESWEGEN ist z.B. eine zentrale/remote Erfassung von Logs sinnvoll.

    Und z.B. genau das kann Journard nicht "von scratch".

    Ich würde allerdings versuchen, entweder eine permanente Ausgabe des Logs (gestartet über eine Service-Unit) auf einen Port zu pipen und den Port auf dem Zielsystem in ein File schreiben, oder den Stream via ncat über eine SSL-Verbindung zu senden. Gegebenenfalls, wenn das ausreichend wäre, würde ich auch nur zyklisch ein zeitlich festgelegtes Log-Paket senden. Welches die beste Lösung ist, entscheiden die betrieblichen Bedingungen, Normen, Regeln, Verträge... keine Ahnung. Aber wie gesagt, das hat hier ganz bestimmt keine Bewandnis für Hofei's Problem... und für solchen exotischen (aus Sicht privater Anwender) Anforderungen kann das redundante rsyslog auch durchaus eine Lösung sein.

    Versuchen?

    Hast du also noch nicht gemacht.

    Deine Konstruktion hört sich zwar recht spannend an, aber letztlich Gebastel und gibt es da seit vielen Jahre etwas etabliertes...

    Und das Ganze hat evtl. doch etwas mit Hofei 's Problem zu tun:

    In seiner jetzigen Situation kann er nicht mal mehr die Logs (egal ob Journald oder "old school" auslesen, weil sich das System abgehängt hat.

    Mit remote-Log bestände eine Restchance, noch Logeinträge bis kurz vor dem Desaster zu bekommen, welche weitere Hinweise zum Problem liefern.

    BTW:

    Wer legt eigentlich fest, welche Szenarien im Privaten Umfeld "normal" und "exotisch" sind?

  • Hast du also noch nicht gemacht.

    Nein, bei mir ist das ganz einfach auf eine SSD gemountet.... und das würde vermutlich innerhalb des Netzes auch einfach auf eine beliebige gemountete Netzplatte funktionieren. Wichtig ist nur, dass der mount in der Boot-Phase zwingend vor dem Flush des Journals erfolgen muss, aber das ist ja einfach. Und man braucht einen Handler, wenn die Platte oder das Netz nicht verfügbar ist.... aber auch das nicht so ein Problem. Ich bin nur durch die Einbeziehung eines TCP oder UPD-Transports davon ausgegangen, dass das ggf. auch "entfernt" übertragen werden muss... das ist natürlich anspruchsvoller, aber im Heimnetz ist das imho einfach.

  • Moin!

    Ich weiß nicht wohin diese OT-Diskussion führen soll..

    Und das Ganze hat evtl. doch etwas mit Hofei 's Problem zu tun:

    In seiner jetzigen Situation kann er nicht mal mehr die Logs (egal ob Journald oder "old school" auslesen, weil sich das System abgehängt hat.

    Nach "old school" würde etwas zum Fehler in /var/log/syslog oder /var/log/messages stehen. Scheint aber nicht so, das kann aber an der Weiterleitung an das "alte" System liegen.

    Mit remote-Log bestände eine Restchance, noch Logeinträge bis kurz vor dem Desaster zu bekommen, welche weitere Hinweise zum Problem liefern.

    Das ist eigentlich ganz einfach. Wenn man nichts an der /etc/systemd/journald.conf geändert hat, dann reicht ein einfaches sudo mkdir /var/log/journal aus, damit journalctl direkt in eine Datei schreibt und nicht mehr in den Speicher.

    Bleibt die Frage ob ein Remote-Log_System schneller ist...

    Gerade wenn ich einen headless-Pi habe und zu dessen SD-Karten Schutz u.a. das /var/log Verzeichnis nicht beschreiben will, jedoch die Logs dennoch nach einem ggf. erfolgten Power-down oder einem anderen Fehlerzustand auswerten will, nützt mir das oft beschriebene Verlegen des /var/log-Verzeichnis (oder wo immer eben auch Journald seine Logs hinschreibt) in den RAM nichts, weil die dann weg sind.

    Wenn Hofei ein ReadOnly-Sytem hätte, dann braucht er auch nicht wöchentlich eine Sicherung anlegen!

    Aber das ist nun Haarspalterei von mir.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Wenn Hofei ein ReadOnly-Sytem hätte, dann braucht er auch nicht wöchentlich eine Sicherung anlegen!

    Aber das ist nun Haarspalterei von mir.

    Wenn wir schon Haare spalten, jeden Monat wird eine Sicherung erstellt ;):)

    Vorerst liegt das ganze auf Eis, irgendwann werd ichs nochmals versuchen wenn es die Zeit wieder leichter zulässt. Bis dahin gibts dann eh ein Update das den Fehler behebt ^^

    Auch wenn manches OT war/ist, da Logs bei mir viel zu kurz in meinem Linux darsein gekommen sind, so bin ich auch solche Informationen dennoch dankbar

  • Ich möchte mich an dieser Stelle auch melden.

    Ich verwende seit einigen Jahren raspibackup von framps, das bei mir sowohl tar als auch wieder verstärkt dd-Images meiner gewachsenen Raspi-Familie im SmartHome erstellt. Auf ein Qnap-NAS mit NFS-Freigabe.

    Nachdem ich mein Master-System mit fhem auf den Raspi3b+ angehoben habe (Raspian Stretch, das zuvor problemlos auf einem Raspi3 lief), und apt-get upgrade sowie dist-upgrade erst Anfang Mai 2018 durchgeführt habe, hatte ich das Problem, dass dd-Image nicht mehr durchgelaufen sind.

    Nicht reproduzierbar wurden von der 16GB-SD entweder nur wenige hundert MB, manchmal auch 14GB und ganz selten auch die komplette SD auf mein Qnap-NAS weggeschrieben.

    Defekt an der SD kann ich ausschließen, da ich testweise eine andere SD verwendet habe.

    Auch habe ich zwischenzeitlich einen 2. Raspi3b+ bestellt, um einen einmaligen Hardware-Fehler auszuschließen.

    Die Probleme traten immer noch auf.

    Erst nach Hinweisen aus diesem Thread habe ich dann mal probiert, statt NFS die Samba-Freigabe zu mounten.

    Seither läuft mein raspibackup dd-Image wieder problemlos durch, und die Performance ist auch deutlich besser (22-27 MB/s bei SMB statt 11-15 MB/s bei NFS).

    Eigentlich sollte man meinen, Linux-zu-Linux sollte mit NFS die beste Performance zu haben.

    Dem ist aber offensichtlich nicht so.

    NFS hatte ich übrigens verwendet, da ich mit raspibackup vor einiger Zeit noch rsync-Backups verwendet habe.

    Zwischenzeitlich verwende ich aber wegen der einfacheren Wiederherstellbarkeit sowohl auf einem anderen Raspi als auch unter Windows wieder dd.

    Deshalb benötige ich auch kein NFS mehr.

    Könnte es sein, dass es zu irgendwelchen (Treiber-)Problemen auf dem Raspi3b+ im Zusammenhang mit NFS kommt?

    Viele Grüße,

    Heiko

  • Könnte es sein, dass es zu irgendwelchen (Treiber-)Problemen auf dem Raspi3b+ im Zusammenhang mit NFS kommt?

    Wobei ich die größeren Probleme eben mit Samba habe :conf:, aber auch mit NFS.

    Zz ruht aber die Problemlösung etwas, ich hoffe ja immer noch dass das alles mal durch ein Update sich von Luft auflöst

Jetzt mitmachen!

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