Ungeklärte Neustarts eines Raspberry 3B+

/var/log/syslog mal reingeschaut? dmesg? Stromausfall wird schwierig den die logs sind dann meist noch nicht geschrieben. Testweise ne Powerbank USV dazwischen und schaun obs dann weg is.

Hört sich nach Eierautomat oder Milchtankstelle an. Vermutlich diverse Spannungseinbrüche auf der Versorgung. Kleine USV oder eine durchladefähige Powerbank könnte helfen.

Oliver S. schrieb:

Hört sich nach Eierautomat oder Milchtankstelle an. Vermutlich diverse Spannungseinbrüche auf der Versorgung.

Kommt auf einem Bauernhof durchaus vor, wenn z.B. das Schweissgerät angeworfen wird.

Oliver S. schrieb:

Hört sich nach Eierautomat oder Milchtankstelle an.

Nein, es ist ein "Bezahlautomat" für eine Autowaschanlage. Man kann wahlweise Autowäschen mit Zusatzoptionen (Felgenwäsche, Unterboden ... etc.) als QR-Code oder "Wasch- und Saugmünzen" für die SB-Boxen kaufen.

Die Anlage steht inmitten eines Gewerbegebietes einer mittleren Stadt in Thüringen. Zur Versorgung des Raspi und einiger ESP32 wird ein Meanwell-Hutschienennetzteil 5V/10A verwendet. Die anderen Komponenten (EC-Reader, Drucker, RFID-Reader, Geldscheinleser usw.) haben eigene Netzteile mit 12V oder 24V. Die Kommunikation innerhalb des Automaten erfolgt per LAN, es gibt keine direkten elektrischen Verbindungen.

Die Neustarts passieren bisher ausserhalb der Betriebszeiten der Waschanlage ...

Frank E. schrieb:

Nun kenne ich mich mit dem Unterbau von Raspian nicht so gut aus, deshalb die Frage: Es gibt doch sicher ein systemeigenes Log, wo ich evtl. etwas mehr über die Ursachen der Neustarts erfahren könnte? Wie heisst das und wo finde ich es?

Gibt es schon, wird dir aber sehr wahrscheinlich nicht helfen. Von sich aus löst Raspian natürlich keine Reboots aus. Das ist also irreguläres Verhalten und sowas kann nur von Hardware-Problemen kommen.

Das kann u.U. sichtbare Spuren in den Logs hinterlassen, aber meist tut es das nicht. Dazu kommt, dass diese Spuren, selbst wenn sie existieren, oft nicht die wahre Ursache des Problems addressieren, sondern im Prinzip nur den Schluckauf der Systemkomponente, die (mehr oder weniger zufällig) als erstes mit dem eigentlichen Problem konfrontiert ist.

Wird wohl ein lausiger Hardware-Aufbau, unzureichende Versorgung oder eine defekte Komponente sein.

Frank E. schrieb:

Es gibt doch sicher ein systemeigenes Log, wo ich evtl. etwas mehr über die Ursachen der Neustarts erfahren könnte? Wie heisst das und wo finde ich es?

man journalctl

Statt einer USV reichen vielleicht schon ein paar fette Elkos auf den Versorgungsleitungen. Ausprobieren.

Ich muss den Thread nochmal aufwärmen. Kann mir bitte jemand erklären, anhand der Datei hier:

qualidat.com/material/raspilog.txt

was zu dem Neustart geführt hat? Oder reicht der Ausschnitt nicht aus?

Danke

Da muesste aus dem Forum jemand den gleichen Raspi haben und nachsehen, welcher Schritt danach im Logfile kaeme.

Vielleicht nicht alle Autoupdates abgestellt?

Mit ps ax die hoechste Prozessnummer loggen waere vielleicht eine Idee.

Mit who oder cpu-info bekommst Du die Ontime, wenn Du das in einen Log schreibst. Vielleicht geht da ein Prozess des Journalings los und verursacht einen Refresh.

Das Netzteil hast Du auf 5,3V eingestellt? Pruef das mal nach.

Für weitere Infos, was abgefragt werden könnte: https://elinux.org/RPI_vcgencmd_usage

Frank E. schrieb:

Ich muss den Thread nochmal aufwärmen. Kann mir bitte jemand erklären, anhand der Datei hier:

qualidat.com/material/raspilog.txt

was zu dem Neustart geführt hat? Oder reicht der Ausschnitt nicht aus?

Das sieht so aus als sei nur der snapd abgeraucht. Benutzt Du überhaupt snaps auf diesem System? Wenn nicht würde ich das einmal deaktivieren und maskieren: "systemctl disable snapd.service && systemctl mask snapd.service && systemctl stop snapd.service".

Sheeva P. schrieb:

Das sieht so aus als sei nur der snapd abgeraucht. Benutzt Du überhaupt snaps auf diesem System? Wenn nicht würde ich das einmal deaktivieren und maskieren: "systemctl disable snapd.service && systemctl mask snapd.service && systemctl stop snapd.service".

Nö, jedenfalls nicht bewusst. Eigentlich nutze ich den Rspi wie einen kleinen PC. Es läuft eine Anwendungssoftware (erstellt in Xojo) darauf (per AUtostart) und es gibt einen Crontab-Eintrag zum Neustart täglich 4 Uhr. Die Anwendung kommuniziert ausschließlich per LAN mit ihrer Umgebung ... also auch keine GPIO-Nutzung. Ein HDMI-display ist noch dran.

Das von dir vorgeschlagene Kommando stellt den Service dauerhaft ab, oder muss der Befehl nach jedem Neustart ausgeführt weden?

Frank E. schrieb:

Das von dir vorgeschlagene Kommando stellt den Service dauerhaft ab, oder muss der Befehl nach jedem Neustart ausgeführt weden?

So ist es. Eigentlich müßten "disable" + "stop" reichen, "mask" ist nur als Fallback da... einige dieser Dienste sind durchaus hartnäckig und winken Dir nach dem nächsten Update plötzlich wieder zu.