Hallo zusammen, ich betreibe einen Raspberry Pi (Pi 3 Model B ) unter Raspian (4.9.80-v7). Es laufen: -apache -mysql bzw. mariaDB -ein python-Programm (schreibt Daten von UART in eine mySQL DB) Etwa einmal pro Monat kommt es vor, dass plötzlich kein ssh-Zugriff mehr möglich ist und auch der apache nicht mehr zu funktionieren scheint (kein Zugriff auf die Startseite möglich). Das letzte mal ist dies am 25.04. passiert. ssh Zugriff war unmöglich und der apache zeigte für jede Seite "Forbidden You don't have permission to access / on this server" an. Nach einem Neustart durch Stecker raus und wieder rein funktionierte alles wieder normal. Im Anhang ist /var/log/messages und die /var/log/syslog, die die Logs um den Zeitpunkt des Aufhängens (25.04. etwa 18h) zeigen. Zu diesem Zeitpunkt hat zumindest das Python Programm aufgehört zu arbeiten. Lässt sich damit die Ursache schon eingrenzen? In welchen Logs könnte ich noch nachschauen? Gruß Dennis
Zeno schrieb: > Startest Du irgendwelche Scripts die Dateien erzeugen? Welche Dateien meinst du? Bei der Erzeugung der Logs "wirke ich nicht aktiv mit". Die werden vom raspian/Debian erzeugt. Die einzige von mir selbst geschriebene laufende Software ist das python Programm.
Dennis schrieb: > Die einzige von mir > selbst geschriebene laufende Software ist das python Programm. Hast du ein Speicherleck und die Software verbraucht immer mehr Speicher, bis irgendwann keiner mehr da ist? Guck einfach mal alle paar Tage nach, wie viel RAM die einzelnen Anwendungen brauchen.
Ma W. schrieb: > Hast du ein Speicherleck und die Software verbraucht immer mehr > Speicher, bis irgendwann keiner mehr da ist? Nein, habe den RAM verbrauch mit htop überwacht. Das python Programm verbraucht maximal 20MB ram.
Dennis schrieb: > Das python Programm > verbraucht maximal 20MB ram. Und der ganze Rest? Mein Raspi ist auch nach einiger Zeit immer mehr ausgestiegen, mir war nicht klar dass bei der Installation die Partition schon randvoll ist und dass man als erstes die Partition vergrössern muss, weil bei der Installation nur ein Bruchteil der Speicherkarte benutzt wird. Georg
georg schrieb: > Und der ganze Rest? Mein Raspi ist auch nach einiger Zeit immer mehr > ausgestiegen, mir war nicht klar dass bei der Installation die Partition > schon randvoll ist und dass man als erstes die Partition vergrössern > muss, weil bei der Installation nur ein Bruchteil der Speicherkarte > benutzt wird. > > Georg Sprichst du von RAM oder flash/Festplattenplatz (ich habe eine SD-Karte für die boot-Partition, aber den ganzen Rest auf einer 1TB WD red in einem USB Gehäuse) pi@raspberrypi:~ $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 960379920 5218332 906307164 1% / devtmpfs 470180 0 470180 0% /dev tmpfs 474788 0 474788 0% /dev/shm tmpfs 474788 12352 462436 3% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 474788 0 474788 0% /sys/fs/cgroup /dev/mmcblk0p1 42131 21472 20659 51% /boot tmpfs 94956 0 94956 0% /run/user/1000
Dennis schrieb: > Sprichst du von RAM oder flash/Festplattenplatz Vom Flash. Üblicherweise lädt man ja ein IMG herunter, das auf die SD-Karte kopiert wird. Das ist oft gerade so gross wie nötig, bei mir waren das soweit ich mich erinnere 2 GB (die Karte hat 16), und die 2 GB auf der Karte waren unmittelbar nach der Installation schon zu 95% voll. Logischerweise ging das nach den ersten Updates schief. Muss man halt drauf achten. Georg
georg schrieb: > Vom Flash. Üblicherweise lädt man ja ein IMG herunter, das auf die > SD-Karte kopiert wird. Das ist oft gerade so gross wie nötig, bei mir > waren das soweit ich mich erinnere 2 GB (die Karte hat 16), und die 2 GB > auf der Karte waren unmittelbar nach der Installation schon zu 95% voll. > Logischerweise ging das nach den ersten Updates schief. Muss man halt > drauf achten. > > Georg Das sollte ja bei mir dank der 1tb Festplatte kein Problem werden.
Bei Linux ist doch klar dass es sich Urin baszelsystem handelt... Da stürzt halt mal was ab... Es is einfach so... Und das sollte man vorher wissen...
Wolfgang H. schrieb: > Bei Linux ist doch klar dass es sich Urin baszelsystem handelt... Da > stürzt halt mal was ab... Es is einfach so... Und das sollte man vorher > wissen... Was ist denn die typische Vorgehensweise, wenn ich sicherstellen MUSS, dass ich die Kiste ein Jahr lang alleine lassen kann? Ein watchdog? Jeden Tag neustarten? ...?
Wolfgang H. schrieb: > Bei Linux ist doch klar dass es sich Urin baszelsystem handelt... Da > stürzt halt mal was ab... Es is einfach so... Und das sollte man vorher > wissen... Mein Raspberry PI 2 läuft seit einem Jahr im Dauerbetrieb mit Apache und hat seither keinen Neustart. Als Bastelsystem würd ich das auch nicht mehr bezeichnen. Der Hase warum das abstürzt muss wo anderst begraben sein. (Genau wie der meines Desktopsystems, das mal 2 Tage durchläuft und dann ohne erkennbaren Grund alle 10 Minuten 3 mal abstürzt)... und nein, das Ram ist es hier nicht.
Wolfgang H. schrieb: > Bei Linux ist doch klar dass es sich Urin baszelsystem handelt... Da > stürzt halt mal was ab... Es is einfach so... Und das sollte man vorher > wissen... Musst du diese Diskussion jetzt zu Linux vs Windows werden lassen? Des weiteren laufen auf fast allen Servern Linux und die werden von Leuten betrieben, die ganz bestimmt mehr Ahnung haben als du! Ivo
Wolfgang H. schrieb: > Bei Linux ist doch klar dass es sich Urin baszelsystem handelt... Da > stürzt halt mal was ab... Es is einfach so... Und das sollte man vorher > wissen... Ja klar! Hast Du schon mal überhaupt was mit Unix/Linux gemacht? Ich sage mal nein. Unixsysteme sind i.d.R sehr stabil. Der RasPi meiner Wetterstation z.B. läuft seit mehr als 4 Jahren ohne Ausfälle. So viel mal zum Bastelsystem. Hängen geblieben ist er nur vor 4 Wochen, weil ich einen richtigen Bug in mein Script rein gebaut habe. Da kann aber das System nichts dazu, das war einzig und alleine meine Unbedachtheit. Dennis schrieb: > Welche Dateien meinst du? Bei der Erzeugung der Logs "wirke ich nicht > aktiv mit". Die werden vom raspian/Debian erzeugt. Die einzige von mir > selbst geschriebene laufende Software ist das python Programm. Wenn das Python Programm in Dateien schreibt kann das durchaus passieren, das er sich irgendwann ins Nirwana katapultiert. Ich erläutere mal mein Szenario, was mir in den letzten Tagen passiert ist. Vielleicht ist das für Dich ein Denkanstoß. Also wie oben geschrieben habe ich eine Wetterstation. Selbige wird von einem recht umfangreichen Bashscript, welches auf einem RasPi läuft, regelmäßig ausgelesen. Das Script schreibt die Daten in eine RRD-Datenbank und bereitet sie auch so auf, das sie dann auf einer Webseite dargestellt werden können. Zusätzlich hat das Script auch die Erstellung diverser Charts mit den Wetterdaten angestoßen. Das Script wird jede Minute durch einen Cronjob ausgeführt. Hat bisher auch prima funktioniert. Jetzt habe ich vor 14 Tagen das Bildformat der Charts vergrößert und auch deren Anzahl erhöht, so das die Zeit von einer Minute nicht mehr ausgereicht hat um die Chart zu erstellen. Da nach einer Minute durch den Cronjob das Script erneut ausgeführt wurde, obwohl das vorherige noch nicht beendet war, wurden auch wieder neue Programminstanzen mit der Software zur Chartgenerierung gestartet, wodurch das System immer langsamer wurde bis es letzendlich mehr oder weniger zum Stillstand kam. Interaktion von außen war praktisch nicht mehr möglich. Rausgefunden habe ich es dann letztendlich durch Anschluß eines Monitors und einer Tastatur direkt an den Pi. Der Befehl ps -A hat mir dann gezeigt, das es sehr viele Instanzen des Scriptes und des Chartgenerierungstools gab und es wurden immer mehr. Gelöst habe ich das Problem, indem ich die Generierung der Charts herausgelöst habe und sie nunmehr über einen eigenen Cronjob mit größerem Intervall verwalte. Also schau mal nach ob eventuell viele Instanzen Deines Pythonscriptes laufen und die das System immer mehr ausbremsen.
Ja... Hate Linux in Betrieb... Über ein Jahr... Bis zum Stromausfall...
Zeno schrieb: > Unixsysteme sind i.d.R sehr stabil. Der RasPi meiner Wetterstation z.B. > läuft seit mehr als 4 Jahren ohne Ausfälle. So viel mal zum > Bastelsystem. ja aber viele scripts sind nur schnell zusammengebastelt. So lief bein NAS2001b immer ein LOG Eintrag über bis die Kiste stand. Abhilfe war die Logs zu übberwachen mit einem Cronjob und immer die Zeilen über 100 zu löschen. Ich hatte mal ein NAS RaidSonic IB-NAS2001-B Icy Box NAS-System das hat immer den Webserver verloren, die LOGs liefen über! also per SW ein cut der LOGs eingeführt mit tail die letzten 100 Meldungen das die Log Datei nicht die Platte sprengt! Ursache war Absturz des Webservers, warum wieso, bin ich als User der Ursachenforscher? das ist nun wirklich nicht die Aufgabe des Users! Das Problem betraf alle RaisSonic Nutzer der 4220 & 2001b also wurde als würgaround eingeführt, Dienst vorhanden prüfen wenn nicht Prozess kill und Prozess Neustart! http://forum.nas-forum.org/index.php?page=Thread&postID=1648&highlight=#post1648 Ich weiss ist Krampf aber die schnellste Lösung! Beim raspi schmiert immer Chromium ab wenn es nur lange genug läuft. Neustart ist eine Lösung, die andere wäre wieder Ursachenforschung, aber ich habe keinen Bock mehr an Symptomen rumzudoktern
Joachim B. schrieb: > Abhilfe war die Logs zu übberwachen mit einem Cronjob und immer die > Zeilen über 100 zu löschen. Um dieses Problem zu lösen wurde logrotate erfunden. Dieser Dienst kümmer sich um die Verwaltung der Logdateien, indem er selbige komprimiert und alte Dateien nach einem bestimmten Zeitpunkt löscht. Das ist ist halt die Crux mit den Logdateien, die einerseits sehr nützlich sind aber andererseits auch die Platte zumüllen wenn sie überhand nehmen. Man muß hier einen Kompromiß finden. Man kann aber das Logging auch abschalten. Ja mit Chrome habe ich auch so meine Probleme, aber nicht auf dem Raspi. Auf meinen Raspis läuft generell kein X11. Klar kann man auf dem Raspi auch X11 laufen lassen, aber wirklich performatnt ist das nicht. Gerade die älteren Exemplare sind mit einer grafischen Umgebung eher überlastet. Meine Raspis erfüllen im wesentlichen nur Steuerungsaufgaben und sammeln Daten (z.B. von meiner Wetterstation) ein und bereiten diese eventuell noch auf. Dafür braucht es kein X11. Die Systeme sind alle minimal aufgesetzt und beinhalten nur das Nötigste um die gestellte Aufgabe zu erfüllen. Für administrative Zwecke gibt es halt einen SSH Zugang. Schreibzugriffe auf die SD Karte wurden so gering wie möglich gehalten und gehen gegen Null. Daten werden alle auf NFS Volumes geschrieben. Für den Fall das die Netzwerkverbindung mal nicht funktioniert hat z.B. der Raspi der bei mir die Wettersatellitendaten aufzeichnet noch eine kleine SSD. Wichtig bei der ganzen Raspigeschichte ist halt das man auf die SD Karte im Normalbetrieb möglichst nichts schreibt. Das erhöht die Lebensdauer ungemein.
Zeno schrieb: > Wichtig bei der ganzen Raspigeschichte ist halt das man auf die SD Karte > im Normalbetrieb möglichst nichts schreibt. boot von USB ist ja erst bei den neueren implementiert, aber dafür dann eine HDD oder vielleicht doch SSD anklemmen... ne da kaufe ich lieber für 7,-€ eine neue microSDHC alle paar Jahre, nur umkopieren und einrichten nervt, so viel musste ich bei meinen PCs nie machen die laufen und liefen länger als jeder PI bis jetzt. Nur einmal ist mir eine Platte gestorben IBM DTLA, sonst immer der ganze Rechner nach 8 Jahren(2004-2012), mein Lapptop läuft schon 12 Jahre (2006-jetzt)
Nur so eine Vermutung, aber vielleicht verliert der PI die Verbindung zu einem Speichermedium. Ich hatte mal eine 1TB Festplatte, die hat manchmal während der nutzung entschieden sich wieder auszuschalten.
Joachim B. schrieb: > boot von USB ist ja erst bei den neueren implementiert, aber dafür dann > eine HDD oder vielleicht doch SSD anklemmen... HDD geht auch mit alten Pi's. Auf der SD muß nur eine Partition sein die das Bootverzeichnis enthält. Der Rest kann auf einer HDD sein. Um die SD zu schonen reicht es allerdings, wenn man die Verzeichnisse wo viel geschrieben wird auf eine HDD auslagert. Um das zu realisieren muß man allerdings schon selbst Hand anlegen. die vorgefertigten Images sind da eher nicht geeignet. Joachim B. schrieb: > ne da kaufe ich lieber für 7,-€ eine neue microSDHC alle paar Jahre, nur > umkopieren und einrichten nervt, so viel musste ich bei meinen PCs nie > machen die laufen und liefen länger als jeder PI bis jetzt. Das ist halt in sofern Mist wenn dabei Daten verloren gehen. Ab Jahren und an mal die SD als Image sichern hält die Schmerzen aber deutlich geringer. Der Pi (1) meiner Wetterstation läuft seit 6 ununterbrochen ohne Ausfälle. Wenn's wirklich mal geklemmt hat, dann war es meine Schuld - schrieb ich aber schon oben. Daniel A. schrieb: > Nur so eine Vermutung, aber vielleicht verliert der PI die Verbindung zu > einem Speichermedium. Ich hatte mal eine 1TB Festplatte, die hat > manchmal während der nutzung entschieden sich wieder auszuschalten. Das bringt mich noch auf eine andere Idee: Hast Du eine stabile Stromversorgung?
Zeno schrieb: > Der Pi (1) meiner Wetterstation läuft seit 6 ununterbrochen ..... Richtig: Der Pi (1) meiner Wetterstation läuft seit 6 Jahren ...
Zeno schrieb: > Das ist halt in sofern Mist wenn dabei Daten verloren gehen. nicht beim PI, ich sichere ja auf dem NAS und lese von da verlorende Daten auf der SD kann ich verschmerzen, nur die Änderungs und Einrichtungsarien nicht mit Jessie hatte ich kein Stress mit der FSTAB nun unter Stretch treibt mich das in den Wahnsinn NAS wird per fstab sofort gemounted, die beiden anderen PIs zicken sowas von rum, aber halt das lief davor osmc(mit Platte) zu jessie@pixel(lesender PI), warum stolpert es von osmc(mit Platte alles wie vorher) zu stretch(lesender PI)? wie ein blinker: geht, geht nicht, geht halb, absturz
:
Bearbeitet durch User
Wolfgang H. schrieb: > Bei Linux ist doch klar dass es sich Urin baszelsystem handelt... Da > stürzt halt mal was ab... Es is einfach so... Und das sollte man vorher > wissen... Eh, deswegen läuft ja auch jeder hochverfügbare Server damit.
Joachim B. schrieb: > mit Jessie hatte ich kein Stress mit der FSTAB nun unter Stretch treibt > mich das in den Wahnsinn Die fstab geht auch mit Stretch, habe ich vor 14 Tagen gemacht. Gegen die Schmerzen bei kaputter SD hilft ein rechtzeitiges SD-Image sehr. Allerdings hatte ich bisher keine Ausfälle einer SD, aber gut ich schreibe ja nicht drauf.
Dennis schrieb: > In welchen Logs könnte > ich noch nachschauen? Kernel-, X- und Apache-Logs. Allerdings steht eventuell nichts Hilfreiches drin, denn anscheinend wird ja Deine "Festplatte" -- die SD-Karte -- quasi hart ausgehängt oder zumindest readonly gemountet. Wenn das das Problem ist, können Deine Logdateien auch nicht mehr persistiert werden. Da kann es helfen, auf einen Remote-Loghost zu loggen. Außerdem vielleicht mal das Paket sysstat zum periodischen Lesen, Speichern und Ausgeben der Performancecounter im Linux-Kernel installieren, um so zu schauen, ob da nicht vielleicht doch irgendwo ein Memory Leak vorliegt.
Karl Käfer schrieb: > Außerdem vielleicht mal das Paket sysstat zum periodischen Lesen, > Speichern und Ausgeben der Performancecounter im Linux-Kernel > installieren, um so zu schauen, ob da nicht vielleicht doch irgendwo ein > Memory Leak vorliegt. sysstat habe ich jetzt mal installiert. Vielleicht reicht das ja schon für eine Diagnose. Wie ich die Stromversorgung und die Festplatte überwachen soll habe ich noch keine Idee.
Zeno schrieb: > Die fstab geht auch mit Stretch, habe ich vor 14 Tagen gemacht. nun jetzt ja, offensichtlich war samba nicht drauf oder nicht richtig installiert, als ich die version finden wollte.... samba nachinstalliert, laufwerke richtig benannt, Freigaben gegeben (rem Ermahnung an mich Linux ist case sensitiv doof halt wenn ein Platte 3tb Kleinschrift heisst die andere 3TB_2 Großschrift und dem win das egal ist oder nicht richtig gezeigt wird.)
Joachim B. schrieb: > Linux ist case sensitiv Ja da muß man aufpassen wie ein Heftelmacher - Windoof ist es halt egal.
Dennis schrieb: > Wie ich die Stromversorgung und die Festplatte überwachen soll habe ich > noch keine Idee. Ist wahrscheinlichlich schwierig. Sorge einfach dafür, das das NT entsprechend potent ist und die Kabel nicht zu dünn sind. Gerade Kabel werden manchmal unterschätzt, insbesondere dann wenn sie etwas länger werden. Hatte jetzt erst so einen Fall mit einem 1-Wire-Bus. Nachdem ich das Kabel gegen CAT6 Kabel getauscht habe funktioniert es jetzt zuverlässig. Das hat mir aber sehr deutlich aufgezeigt, das man so etwas nicht unterschätzen sollte.
Daniel A. schrieb: > Nur so eine Vermutung, aber vielleicht verliert der PI die Verbindung zu > einem Speichermedium. Ich hatte mal eine 1TB Festplatte, die hat > manchmal während der nutzung entschieden sich wieder auszuschalten. da kann es zu dem Zeitpunkt - wenn nichts mehr geht - auch sinnvoll sein, einfach mal die letzten Zeilen von dmesg anzusehen...evtl. meldet da der USB-Port oder das USB-Device einen Fehler als Anhaltspunkt.... z.B. einen Remount
:
Bearbeitet durch User
Zeno schrieb: > Joachim B. schrieb: >> Linux ist case sensitiv > > Ja da muß man aufpassen wie ein Heftelmacher - Windoof ist es halt egal. Eigentlich ist es umgekehrt, linux macht keine Spezialsachen, zwei unterschiedliche Zeichen sind nunmal nicht gleich. Aber Windows versucht herauszufinden welche die selben sind. Linux hat keine Probleme mit caseinsensitiven Dateisystemen. Windows hingegen ist hier komplett kaputt. Ich weiss nicht, ob es zumindest im WSL repariert wurde, aber anderswo kommt es mit case sensitiven Dateisystemen einfach nicht klar. Es gibt zwar einstellungen dafür, aber da Windows erwartet, das Anwendungen bei jeder Dateioperation ein Flag mitliefert, geht es nicht. Und abfragen über reparse points konvertieren einfach alles zu uppercase!! Und versuche mal 2 Files auf einen UDF stick zu platzieren, deren Namen sich nur in der gross klein schreibung unterscheiden. UDF ist case sensitive, aber windows öffnet immer nur eines der Files, egal welches man anclickt! Aber natürlich ist das kein Bug, nur ein Feature. Und wenn man ein case-sensitives Dateisystem implementieren will, erwarten die doch tatsächlich, dass man den Mist mitmacht, und jedesmal jeden Eintrag durchgeht und auf case insensitive match prüft! Total unperformant, speziell bei Netzwerkdateisystemen. Immerhin scheinen sie das umbennenen endlich hinbekommen zu haben, wenn man nur die gross klein schreibung ändert.
Auch wenn die Diskussion hier etwas weg gedriftet ist, habe ich etwas neues zur Sache beizutragen. Gestern Abend konnte ich nicht mehr über ssh, grafana, rdp, ... auf den PI zugreifen. Heute morgen funktionierte wieder alles. Die Einträge in /var/log/messages deuten auf ein Speicherproblem hin. Mir wird zwar aus den Einträgen klar, dass sich der oom_reaper "spontan" dazu entschlossen hat das lxpanel zu beenden, aber die Ursache für den vollen Speicher erkenne ich nicht. Hat dazu jemand eine Idee? Vielen Dank!
Sowas passiert eigentlich nur auf Systemen die keinen Swapspace haben. Also leg einen an. Muss nicht gross sein. 1/2 GB reicht. Natuerlich auf der Platte und nicht auf der SD.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.