Bash/Shellscript: Script läuft. Aber RAM läuft voll => Raspi hängst sich auf

  • Hallo, mal wieder eine Frage an die Experten:

    Habe ein bash Skript geschrieben das auch tut auch was es soll. Aber nach einigen Minuten hängt sich der Raspi auf.

    Habe mit htop verfolgt wie sich der RAM immer mehr füllt wenn das Skript läuft, obwohl eigentlich garkeine Daten dort abgelegt werden. Werden sie aber offenbar doch!

    Hat da jemand ne Idee?

    Hier das Skript:

    :conf::conf::conf:

    Grüsse.

  • Bash/Shellscript: Script läuft. Aber RAM läuft voll => Raspi hängst sich auf? Schau mal ob du hier fündig wirst!

  • Hm, wenn ich deine Zeile teste kommt bei mir nur awk: line 2: function strftime never defined

    Vermutlich müsste ich da erst eine Komponente installieren.

    Du suchst vermutlich nur nach der Zeile in der "Quality" steht. Das geht aber hier nicht, da beim Scan ja ganz viele WLANs angezeigt werden, jeweils mit einer Zeile in der "Quality" steht. Du musst also erstmal das gewünschte WLAN herausfiltern.

    Irgendwo innerhalb der 12 Zeilen nach der Auflistung der SSID von Interesse steht die relevante Zeile. Also diese 12 Zeilen herausfiltern und dann ganz einfach mit grep darin suchen.

    Funktioniert wie gesagt auch alles bestens. Aber der RAM läuft eben über!

    Kannst es ja mal testen ;)

  • > Hm, wenn ich deine Zeile teste kommt bei mir nur awk: line 2: function strftime never defined

    Schade, dann ist es kein gawk oder eine aeltere Version

    Was passiert ohne strftime?

    > Du suchst vermutlich nur nach der Zeile in der "Quality" steht. Das geht aber hier nicht, da beim Scan

    > ja ganz viele WLANs angezeigt werden, jeweils mit einer Zeile in der "Quality" steht.

    Das Script sucht nach Quality und speichert die Zeile. Wenn das gesuchte wlan erkannt wird, gibt es die gespeicherte Zeile wieder aus. Einzige Voraussetzung: Quality muss vor dem gesuchten wlan stehen.

  • Mit deiner Zeile ohne str... bekomme ich massig Zeilen in denen Quality steht. Wie gesagt, so kann das auch nicht gehen weil in der Ausgabe von iwlist viele Zeilen mit Quality darin stehen, eine pro WLAN.

    Ich will auch kein neues Skript schreiben. Das Skript tut genau was es soll, bis eben auf die Daten die es im RAM abzulegen scheint.

    Weiß jemand wie es kommt dass der RAM so schnell vollgeschrieben wird und wie man das vermeiden kann?:conf:

  • Vielleicht kannst du mit z.B. free an diversen stellen im Skript den benutzten Speicher ausgeben lassen um zu sehen wo genau der Speicher Verbraucht wird. Oder das Skript minimalisieren (Teile auskommentieren) und gucken, ob sich etwas ändert.

  • iwlist wlan0 scan > scan

    ist Pfusch, und jedes weitere Vorkommen des Dateinamens "scan"

    Verwendet etwas, was nicht als Parameter eines Befehls verstanden werden kann.

    Also z.B. 'scan.txt' für die Datei.

    Noch was:

    Ja, es ist umständlicher zu tippen, doch es hilft ungemein, wenn man die Variablen lass '$variable' sondern als '${variable}' schreibt.

    Computer ..... grrrrrr

  • Soso, aha. Ich dachte die Dateiendung ist nicht zwingend erforderlich und dient nur der Orientierung, zumindest an dieser Stelle, da sie nur temporär von Interesse ist und eigentlich nach Beendigung des Skripts sowieso gelöscht werden soll. Egal, ich sie der Übersicht wegen mal in scan.log umgenannt.

    Dann ist mir noch aufgefallen dass ich statt

    Code
    line=$(cat scan.log | grep -n $wlan | cut -d: -f1) # Gesuchtes WLAN

    auch

    Code
    line=$(grep -n $wlan scan.log | cut -d: -f1) # Gesuchtes WLAN

    schreiben kann.

    Alles nur Kosmetik! Die wachsende RAM-Belegung hält trotzdem an. :denker:

    Auch das Löschen von scan.log in jeder Schleife ändert nix, weil sie im nächsten Durchlauf ja sowieso mit dem neuen Ergebnis überschrieben wird.

    Aber: Wenn ich die Zeile

    Code
    iwlist wlan0 scan > scan.log # Ergebnisse des scans

    mal vor die Schleife setze (nur testweise sinnvoll weil immer die gleichen Ergebnisse kommen werden), dann steigt die RAM-Belegung nicht weiter an:!:

    Diese Zeile scheint also den RAM vollzuschreiben.

    So weit so gut. Aber so macht das Skript ja keinen Sinn:lol:

    Hat noch jemand eine Idee? :conf::conf: Eine Idee die das Problem löst bitte. Um Kosmetik geht mir's nicht.

  • Das Script läuft und erfuellt seinen Zweck. Soweit so gut. Es macht aber macht viele Dinge umstaendlich. Warum es Speicherprobleme gibt sehe ich nicht. Ich koennte mir vorstellen es liegt irgendwie an der unkonventionellen Verwendung von der Datei scan.

    Extrahiere doch mal die Dich interessierende Info etwas einfacher in Deinem Script.

    Methode: Greppe nach allen Zeilen mit ESSID und Quality, dann greppe nach Deiner ESSID und zeige zusaetzlich die vorherige Zeile (die Quality Zeile) an und zum Schluss loesche die Zeile mit ESSID da Du nur die Qualityzeile sehen willst.

    Code
    iwlist wlan0 scan | grep -E -i "(ESSID|QUALITY)" | grep "$wlan" -B 1 | grep -v "ESSID"
  • Hallo framp und alle.

    Ja danke erstmal für das Mitgrübeln.:thumbup:

    Nun, nach meinem letzten Test (s.o.) ist es extrem unwahrscheinlich dass das was ändern wird. Ich müsste ja trotzdem jedes mal neu zuerst den kompletten Scan erzeugen und dann wie auch immer ausschneiden. Die Datei ist auch nur 8 kB groß. Das kann wohl nicht das Problem sein:lol:

    Selbst wenn alle einzelnen Scanergebnisse sich im RAM aufsummieren würden dürfte die Belegung nicht in dieser Geschwindigkeit (Etwa 1...2 MB pro Schleifendurchlauf) steigen.:conf:

  • Hast Du denn im htop mal die Prozesse nach Speicherverbrauch sortiert ("M")?

    Sicher. Der Prozess selbst belegt 0,3 % des RAM und 0,5 % der CPUs. Und der Wert ändert sich auch nicht. Alles wie man es erwartet eigentlich. Aber oben in dem Mem Balken kann man zusehen wie er steigt und steigt. Das ist nur wenn das Skript läuft.

  • So ihr lieben, ich glaub ich hab's gefunden: Habe das Skript einfach mal mit einem anderen WLAN-Stick laufen lassen. Und siehe da, die RAM-Auslastung bleibt konstant!!

    Es muss also Am WLAN-Treiber liegen und nicht am Skript. Irgendwas macht der im Hintergrund. Und der andere nicht :conf:

    Damit macht man wahrscheinlich ein riesen Fass auf, wenn man an dem Treiber was ändern will... Auf jeden Fall gehört das Thema dann an eine andere Stelle.

    Ich werde eine andere Lösung versuchen.

    :danke_ATDE:

  • Normalerweise geht ein Bugreport an den/die Autor/en der Software (in diesem Fall der Treiber). Erst mal gucken von wem der Treiber ist und wenn vorhanden, die entsprechende Internetseite besuchen.

  • ..., ich glaub ich hab's gefunden: Habe das Skript einfach mal mit einem anderen WLAN-Stick laufen lassen. Und siehe da, die RAM-Auslastung bleibt konstant!!

    Es muss also Am WLAN-Treiber liegen und nicht am Skript. Irgendwas macht der im Hintergrund. Und der andere nicht

    Wie sind mit den beiden WLAN-Sticks, die Ausgaben von:

    Code
    lsmod | grep -i 80211
    iw list
    lsusb

    ?

    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

Jetzt mitmachen!

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