Hallo zusammen,
da ich nicht vorhabe, meinen Raspi (auf dem fhem läuft) jemals zu rebooten, falls es nicht
a) Stromausfall
b) Hardwareänderungen
c) Umzug des Systems
d) Hardwaredefekt
e) Softwarepatching mit Rebootzwang
erfordern, hier nun mal die Frage, was ihr mit euren Raspis für uptimes erreicht, bevor memory leaks o.ä. (falls vorhanden) zu einem Reboot zwingen oder die SD-Karte aufgibt.
Zusatzfrage: Sind bei der jährlichen Umstellung Sommer/Winterzeit und zurück hickups im fhem Event-Modell oder bei den fhem-Timern zu erwarten?
Ich fange mal an:
Raspi V3, relativ neu aufgesetzt, ca. 6 Wochen alt: Up 20 days, 11 hours, 57 minutes.
Hat schon jemand das Jahr voll?
Gruß,
Holger
259 Tage, 18 Stunden, 18 Minuten.
Meiner ist länger ... :-X ;D
Zitat von: CoolTux am 05 Januar 2018, 07:59:45
Meiner ist länger ... :-X ;D
Hallo CoolTux, das soll nicht das Äquivalent zu einem vmax-Thread bei Motor-Talk sein. Mir geht es darum, wieviel präventive Wartung der raspi möglicherweise erfordert.
Zitat von: Thorsten Pferdekaemper am 05 Januar 2018, 07:57:20
259 Tage, 18 Stunden, 18 Minuten.
Hier wurde zu mindest nie ein Kernelupdate gemacht.
Naja, das ist Ansichtssache, ob das bei einem gut laufenden System mehr als einmal im Jahr nötig ist. Für mich wären nur Vulnerability-Patches nötig und das auch nur begrenzt, da mein Raspi nicht im öffentlichen Netz steht.
Ich patche meine VU+ Solo2 auch nicht zeitnah.
Gruß,
Holger
Ich habe einen BananaPi Router als Router und Firewall. Da muss ich dann schon mal öfters Kernel patchen. Nicht immer aber oft.
Wie sieht es denn in dem Zusammenhang mit dem Live-Patching des Kernel aus, das es seit 4.0 gibt? Wird das auf dem Pi irgendwie unterstützt?
Zitat von: Thorsten Pferdekaemper am 05 Januar 2018, 07:57:20
259 Tage, 18 Stunden, 18 Minuten.
255 Tage. 11 Stunden, 29 Minuten seit dem letzten Stromausfall ;)
Gruß PeMue
ZitatLast login: Mon Dec 18 01:05:44 2017 from machine.fritz.box
pi@raspberrypi ~ $ uptime
10:54:45 up 342 days, 13:17, 1 user, load average: 0,14, 0,05, 0,05
Fhem info:
Release : 5.7 FeatureLevel: 5.7
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.14.2
uniqueID : xxxxxxxxxxxxxxxxxx
upTime : 220 days, 17:26:12 Fhem läuft stabil
Hallo fhem-hm-knecht,
wenn ich richtig rechne, hast du 2 Zeitwechsel während deiner Uptime gehabt (Winter->Sommer, Sommer->Winter).
Irgendwelche Unregelmäßigkeiten in fhem, die man an den Stichtagen checken sollte?
Gruß,
Holger
P.S.: Sehe gerade, fhem ist "nur" 220 Tage up, aber immerhin ein Zeitwechsel.
wiederholte tagestimer als gehen(gingen) 1 stunde am 1. tag nach Umstellung falsch. werden ja 1 tag früher berechnet.
ich habs mir angewöhnt, da Stonntags , einen shutdown restart zu machen.
Damit kann ich leben, zumal von den ersten 24h nach der Zeitumstellung mindestens 21h auf einen Sonntag fallen.
Zitat von: mahowi am 05 Januar 2018, 09:02:42
Wie sieht es denn in dem Zusammenhang mit dem Live-Patching des Kernel aus, das es seit 4.0 gibt? Wird das auf dem Pi irgendwie unterstützt?
Mein letzter Stand, 5 Jahre alt, RedHat und SUSE machen es.
Eventuell heute auch Ubuntu.
Zitat von: CoolTux am 05 Januar 2018, 12:43:57
Mein letzter Stand, 5 Jahre alt, RedHat und SUSE machen es.
Eventuell heute auch Ubuntu.
Zumindest auf meinem Laptop wird unter Ubuntu der komplette Kernel ausgetauscht, scheint also nicht implementiert worden zu sein.
Schade, daß es von Raspbian auch nicht genutzt wird. Ein neuer Kernel ist eigentlich der einzige Grund für einen Reboot bei mir.
Naja wenn müsste es ja auch in Debian drin sein. Dann könnte man es auch in rasbian implementieren.
Aber es soll ja auch noch nicht zu 100% klappen.
Hab jetzt mal ein bißchen recherchiert.
In Ubuntu kann man es nur im LTS über ein Snap und ein Access-Token aktivieren. Für Debian-Server gibt es lediglich kommerzielle Anbieter für Live-Patches.
Muss aber auch gestehen daß ich es nie wirklich verstanden habe wieso es so schlimm sein soll nach einem Kernel Patch Mal zu rebooten. Manchmal bemerkt man da erst einen Fehler. In meiner alten Firma gab es mal eine Kiste mit Windows NT, das war 2010. Niemand aber auch wirklich niemand hat sich getraut das Teil zu rebooten. Keine Ahnung wie lange der da schon lief. Das war ein wichtiges Mailgateway. ;D