The Industrial Raspberry Pi Forum

Hallo Volker,

ich musste eben einen Reboot über Putty ausführen da der Pi wo Hängengeblieben ist und ich eine Fehlermeldung von meinem Programm bekommen habe. Keine Verbindung zum Zielsystem.
Nach ca 5-7 min habe ich mich gewundert warum ich noch immer keine Verbindung zum Pi bekomme, also bin ich nachschauen gegangen.
Da habe ich gesehen das zwar der Pi Grün angezeigt hat bei der Staus LED aber das DIO Modul nur ROT. Also alles vom Netz genommen einen Neustart gemacht, aber das DIO Modul ist nur ROT am Blinken gewesen, keine Änderrung.

Kann es sein das es defekt ist? weil 24V liegen überall an. was ich nurt nicht verstehe, wenn das DIO Modul ausfällt wieso habe ich dann keinen zugriff mehr auf den PI? zumindestens über putty oder SSH sollte noch ein zugriff erfolgen.
Aber so wie es gerade ist ist keine Option für mich.

So kann ich das Gerät nicht nutzen wenn überhaupt nichts mehr geht. zumindesten auf den Pi sollte man noch gelangen und da dann sehen das ein Modul ausgefallen ist. Für den Fall das es Defekt ist schicke ich es euch Morgen auch gleich zurück. Ich will aber erst sehen ob ich ohne DIO noch auf den PI komme.

gruß

Hallo Ingo,
das hört sich nict nach Hardwareproblemen an. DIO ist sehr wahrscheinlich völlig in Ordnung. Wenn er rote LEDs zeigt, dann deshalb, weil PiControl keine zyklische Verbindung aufbaut. PiControl läuft auf dem RevPi Core. Wenn der aber nicht vollständig korrekt bootet, dann geht weder SSH noch dir PiBriodge. Wenn DU die beiden LED A und B nict selber in Deiner Anwendung so prorammiert hast, dass Sie Dir anzeigen, ob der Pi in einem bestimmten Betriebszustand ist, dann ast Du am Repi Core direkt keine Möglichkeit headless (ohne HDMI BIldscirm) zu erkennen, was da los ist. DIe grüne LED zeigt ja nur an, dass er Strom hat. SIe würde nur rot gehen, wenn ein gravierender Fehler in der Hardwqare vom Core gefunden wird.
Am besten schließt Du zur Feherlsuche einen HDMI MOnitor (plus Tatsatur an USB) an und schaust, ob und wie das Gerät bootet. Über SSH wirst DU da wenig sehen können.
Ich wünsche DIr viel ERfolg und bin gespannt, was da püassiert ist. Was waren die letzten Aktionen vor diesem Zwischenfall?
Da wir auf er Hannovermesse sind, werden wir nicht so zeitnah wie gewohnt antworten können...

NACHTRAG:
Mir kommt da grade eine Idee: Du verwendest doch neben logi.cad auch noch oftware, die nicht von uns kommt, richtig? Da besteht eine gewisse Chance, dass diese Software Logfiles schreibt. Wir haben schon erelebt, dass es dabei zu einer extensiven Nutzung von Logs kommen kann. Zum Beispiel wenn usner Treiber geöffnet und geschlossen wird, dann wird ein Logeintrag erzeugt. In den frühen Versionen von PiControl war das so per Default. Wenn nun eine Anwendungssoftware den Treiber dauernd mit open zyklisch öffnet tsatt das einmailg beim Strat zu tun, dann kann es pro Sekunde mehrere Logeinträge geben. Das führt dann dazu, dass der eMMC Speicher irgendwann komplett voll ist und sich dann Linux einfach nicht mer booten lässt. Dahilft dann nur noch das Wideraufspielen einer Imagekopiee.
Wenn Anendersoftware ganz normale syslog-Einträge schreibt, dann kann man unter Linux einstellen, wieviel solcher Einträge entstehen dürfen (Log-Level) und auch, wie oft das System die Logfiles "rotiert", d.h. alte schließt und umbenennt, noch ältere löscht und neue beginnt. Für usnere Messemodell haben wir zum Beispiel diese Systemeinstelllungen so eingestellt, dass definitiv keine Fremdsoftware (die wir ja auch auf unseren Systemen haben) den eMMC Speicher voll schreibt. UNsere aktuellen Versionen isnd auch so eingestellt, dass das eigentlich mit unserer Software nicht passieren sollte.
Im neuen Jessi-Image haben wir dann auch die logfile rotation per Default sehr kurzzeitig eingerichtet (ich glaube auf 24h).
Also um dieses Problem zu erkennen und zu lösen musst Du HDMI anschließen udn schauen, was Linux beim Booten für Fehler auswirft. Wenn eien volle Disk das Problem ist und Du nicht mehr booten kannst, dann gibt es für Dich kaum andere Chancen als eine Sicherunsgkopie vom Image einzuspielen...

Hallo Volker,

Sorry bin im Falschen Teil gelandet. KAnnst du es an die Richtige Stelle verschieben.

Also zum Problem:

Wir hatten dem Pi zum Anfang eine Feste IP Adresse in der Config vergeben hatten auch in der Fritzbox gesagt dem Gerät immer die selbe IP zu verpassen. Aber als ich gestern den Reboot ausgelöst hatte hat der DHCP vom PI wo ein kleines Problem gehabt und wollte ihm eine neue IP Zuweisen. Da dies aber nicht gelang wurde der speicher durch eine ? welche der Speicher voll geschrieben so das kein Normaler zugriff mehr möglich gewesen ist.

Lösung:

Nach dem wir wieder volle Kontrolle auf den Pi hatten haben wir einen 8GB grossen USB Stick ( in ext4 Formatiert) so angemountet das er das verzeichniss /var/log übernimmt und alles was an log dateien geschrieben wird nun auf dem Stick erfolgt.
Sollte der Stick mal nicht Vorhanden sein so wird das Ursprüngliche Verzeichniss dazu verwendet.
Zu beachten ist das wir den Stick anhand seiner Kennung eingebunden haben.
Sollte es denoch vorkommen das es wieder durch Speicherprobleme zu diesem Phänomän kommen sollte braucht man den Stick nur abziehen ( Ausgeschalteten Zustand PI ) und diese dann auf einem Linux rechner Ansehen und gegebenfalls löschen. Und er muss auch genau wieder auf den Steckplatz gesteckt werden wo er zum Anfang gesteckt gewesen war.
Der Stick ist so eingebunden das auch nach einem Reboot der Stick vom System erkannt und eingebunden wird.

Kleine Uhrsache aber riesengroße Wirkung da gezwungen gewesen ist den Pi auszubauen um das Problem mit Axel seiner Hilfe lösen zu können.

Das wars dazu ersteinmal.

gruß und noch schöne Tage auf der Messe

Da freue ich mich jetzt sehr, dass Ihr zusammen das Problem so gut in den Griff bekommen habt. Könntest Du Axel bitten, dass er noch mal genau beschreibt, welche log-Datei da so groß geworden ist? War es die syslog und wenn ja, welche task hat die Logeinträge geschrieben? Wenn es eine der von unseren Systemprogrammen gestartete Task war, dann müssen wir da dringend für sorgen, dass das nicht mehr passieren kann. War es aber eine Task einer Software von anderen Herstellern, können wir da nichts dran ändern. Was aber immer gut ist (außer man arbeitet mit einem Stick), ist die Umstellung vom Loglevel auf deutlich weniger Einträge und auch die Umstellung auf kürzere Rotationszeiten von z.B. 24 Stunden.

Hallo Volker,


erst mal danke, du hattest in deinen Nachtrag ein paar gute Tipps gegeben, HDMI war Gold wert! in der Tat ist der Pi im Bootprozess stecken geblieben und ist gar nicht mehr zum Login gekommen. Dank SYSRQ + K konnte ich den Prozess der sich weg gehängt hatte beenden und mich danach wieder Anmelden und auf Spuren suche gehen.

Warum der Prozess der vorher problemlos lief, Amok gelaufen ist konnte ich leider nicht nachvollziehen. ich kann mir nur vorstellen das es mit dem vorherigen ein Problem gab und das damit zusammenhing, der Prozess, ist deshalb wieder aus den Bootprozess raus.

/var/log/messages sowie kernel.log - waren extrem groß, viele Meldungen von piControl Open/release/close teils mehrfach pro Sekunde. Gibt es da eventuell eine Möglichkeit diese Meldungen mittels Kernel Modul Parameter zu deaktivieren, das würde diesen Speicherverbrauch deutlich verringern. Zumal dann wichtige Meldungen leichter zu finden sind, wer hat schon spass daran 1GB Logfile zu durchsuchen, wenn fast nur
drin stehen.

Um den Speicherverbrauch auf den Pi selber zu reduzieren habe ich einen USB Stick formatiert. und mittels die UUID ermittelt um dann folgenden Eintrag in der /etc/fstab gemacht wichtig, dabei die Verzeichnisstruktur vom Ordner /var/log/ auf den USB Stick kopieren nach den nächsten Neustart ist an diesen Punkt der USB Stick eingebunden und ein Zugriff auf die alten Daten nicht mehr so ohne weiteres möglich. Dank UUID wird auch nicht irgendein USB Stick eingebunden sondern nur der für diesen Zweck vorbereitete.
Einen weiteren Vorteil hat es, man kann auch, wenn man nicht mehr an den pi kommen sollte, in den logs nach evtl Problemen suchen.

Okay, alles klar dann: Es geht um ein zweifaches Problem:
1) Eine aufgespielte Software (definitiv nicht LogiRTS) nutzt offenbar PiControl in einer Art, wie man es nicht machen sollte: Zyklisches Öffnen und Schließen vom PiControl Treiber, statt ihn vor dem zyklischen Betrieb im Init einmalig zu öffen und gut isses.
2) Wir hatten pro Öffnen und Schließen einen Logeintrag in PiControl in den frühen Versionen. Diese Einträge werden aus genau dem hier beschriebenen Grund aber inzwischen nicht mehr geschrieben. In dem in den nächsten Wochen online gestellten neuen Image ist dann definitiv dieses Problem nicht mehr vorhanden. Trotzdem empfehlen wir auch aus Performancegründen nicht, den Treiber zyklisch srtändig zu öffenen und zu schließen. Es reicht, wenn die Anwendung sich im Init einmalig den Filehandle vom Treiber besorgt und vor dem Beenden des Programms eien close darauf ausführt.

Hi Ingo!

Volkers Punkt 1 kann ist dir sogar benennen:
Was da dein Protokoll flutet ist euer "run.py" Programm um eure 1-wire Werte auszulesen!

Ihr arbeitet da bei JEDEM Datenpoll mit piTest. Also wird jedes Mal, wenn Ihr einen Wert von 1-Wire holt und den in eurer Virtuelles Device schreibt der piControl geöffnet, da jedes mal piTest aufgerufen wird: Und dann kommen die Logzeilen bei JEDEM Durchlauf

Ihr solltet da versuchen auf z.B. RevPiModIODriver umzustellen, da das Modul den piControl nur bei der Instantiierung EINMAL öffnet und es offen lässt um damit zu arbeiten. (Wenn es nicht bei jedem Durchlaufen der Aktualisierung neu Instantiiert wird - also global instantiieren!)

Ein Beispiel ist hier: https://revpimodio.org/treiber-fuer-vir ... s-pictory/

Gruß, Sven

RevPiModIODrvier (also wirklich DRIVER am Ende!) ist nur für EIN virtuelles Device zuständig und lässt alle anderen Daten vom Prozessabbild ungerührt!!!