NEWS
Raspberry Pi 4 startet nicht mehr
-
sudo systemctl stop grafana* iob stop sudo reboot
-
Obwohl ich brav nach deiner Anleitung vorgegangen bin, bleibt leider alles beim Alten ..
pi@raspiBullseye:~ $ sudo systemctl status grafana-server × grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Wed 2024-12-11 16:01:07 CET; 6min ago Duration: 1.099s Docs: http://docs.grafana.org Process: 1705 ExecStart=/usr/share/grafana/bin/grafana server --config=${CONF_FILE} --pidfile=${PID_FILE_DIR}/grafana-server.pid --packaging=deb cfg:default.paths.lo> Main PID: 1705 (code=exited, status=1/FAILURE) CPU: 1.122s Dec 11 16:01:07 raspiBullseye systemd[1]: grafana-server.service: Scheduled restart job, restart counter is at 7. Dec 11 16:01:07 raspiBullseye systemd[1]: Stopped grafana-server.service - Grafana instance. Dec 11 16:01:07 raspiBullseye systemd[1]: grafana-server.service: Consumed 1.122s CPU time. Dec 11 16:01:07 raspiBullseye systemd[1]: grafana-server.service: Start request repeated too quickly. Dec 11 16:01:07 raspiBullseye systemd[1]: grafana-server.service: Failed with result 'exit-code'. Dec 11 16:01:07 raspiBullseye systemd[1]: Failed to start grafana-server.service - Grafana instance. lines 1-15/15 (END)
Mich irritiert die Meldung: "grafana-server.service: Start request repeated too quickly."
-
@legro sagte in Raspberry Pi 4 startet nicht mehr:
grafana-server.service: Start request repeated too quickly.
Die Meldung kommt, wenn binnen 10 Sekunden 5 mal versucht wird den Service zu starten. Dann wird das abgebrochen, damit das System damit nicht in die Knie gezwungen werden kann.
Die Ursache liegt dann aber außerhalb. Falsche Credentials oder fehlende Rechte. -
@thomas-braun sagte in Raspberry Pi 4 startet nicht mehr:
@legro sagte in Raspberry Pi 4 startet nicht mehr:
grafana-server.service: Start request repeated too quickly.
Die Meldung kommt, wenn binnen 10 Sekunden 5 mal versucht wird den Service zu starten.
So schnell bin ich doch gar nicht.
Wer oder was sollte hier Grafana so oft zu starten suchen?
Wenn ich Grafana erneut versuche zu starten, sieht das Ganze so aus ..
pi@raspiBullseye:~ $ sudo systemctl status grafana-server ● grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; enabled; preset: enabled) Active: active (running) since Wed 2024-12-11 17:14:41 CET; 1s ago Docs: http://docs.grafana.org Main PID: 11151 (grafana) Tasks: 10 (limit: 8755) CPU: 1.472s CGroup: /system.slice/grafana-server.service └─11151 /usr/share/grafana/bin/grafana server --config=/etc/grafana/grafana.ini --pidfile=/run/grafana/grafana-server.pid --packaging=deb cfg:default.paths.> Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=server t=2024-12-11T17:14:42.2609418+01:00 level=info msg="Writing PID file" path=/run/grafana/grafana-server.pid pi> Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=provisioning.alerting t=2024-12-11T17:14:42.26282372+01:00 level=info msg="starting to provision alerting" Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=provisioning.alerting t=2024-12-11T17:14:42.262943126+01:00 level=info msg="finished to provision alerting" Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=provisioning.dashboard t=2024-12-11T17:14:42.266899704+01:00 level=info msg="starting to provision dashboards" Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=provisioning.dashboard t=2024-12-11T17:14:42.267038999+01:00 level=info msg="finished to provision dashboards" Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=server t=2024-12-11T17:14:42.270545694+01:00 level=error msg="Stopped background service" service=*api.HTTPServer re> Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=plugin.signature.key_retriever t=2024-12-11T17:14:42.27130874+01:00 level=error msg="Error downloading plugin manife> Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=infra.usagestats t=2024-12-11T17:14:42.272163895+01:00 level=error msg="Failed to get last sent time" error="context> Dec 11 17:14:42 raspiBullseye grafana[11151]: logger=secret.migration t=2024-12-11T17:14:42.272996718+01:00 level=error msg="Server lock for secret migration already exi> Dec 11 17:14:42 raspi
-
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Wer oder was sollte hier Grafana so oft zu starten suchen?
systemd ist so schnell.
Läuft doch:
● grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; enabled; preset: enabled) Active: active (running) since Wed 2024-12-11 17:14:41 CET; 1s ago
-
@thomas-braun sagte in Raspberry Pi 4 startet nicht mehr:
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Läuft doch:
Leider nein! Ich vergaß, den zweiten Aufruf des Statusbefehls anzufügen. Es sieht immer zunächst danach aus, als ob alles läuft, aber am Ende gibt's doch diese Nachricht ..
pi@raspiBullseye:~ $ sudo systemctl status grafana-server × grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Wed 2024-12-11 17:14:45 CET; 58min ago Duration: 836ms Docs: http://docs.grafana.org Process: 11168 ExecStart=/usr/share/grafana/bin/grafana server --config=${CONF_FILE} --pidfile=${PID_FILE_DIR}/gra> Main PID: 11168 (code=exited, status=1/FAILURE) CPU: 894ms Dec 11 17:14:45 raspiBullseye systemd[1]: grafana-server.service: Scheduled restart job, restart counter is at 5. Dec 11 17:14:45 raspiBullseye systemd[1]: Stopped grafana-server.service - Grafana instance. Dec 11 17:14:45 raspiBullseye systemd[1]: grafana-server.service: Start request repeated too quickly. Dec 11 17:14:45 raspiBullseye systemd[1]: grafana-server.service: Failed with result 'exit-code'. Dec 11 17:14:45 raspiBullseye systemd[1]: Failed to start grafana-server.service - Grafana instance. lines 1-14/14 (END)
-
Nun bin ich‘s endgültig leid. Ich werden Grafana und InfluxDB systematisch und konsequent ersetzen. Diese Agrarinformatiker bin ich einfach leid. Rein in die Kartoffeln, raus aus den Kartoffeln.
Da wird zur Version 2.x InfluxQL abgekündigt und Flux eingeführt. Zur Version 3.x soll nun Flux wieder eingestellt werden. Neue Version, neue Fehler: In der neusten Grafana-Version funktioniert das vollständige Ausblenden der Menüs in eingebetteten Diagrammen mittels des Parameters kiosk nicht mehr. ..
Auch wenn diese Software umsonst daherkommt, ist mir der Preis, den ich mit dem ständigen Rumbasteln bezahlen muss, zu hoch.
-
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Auch wenn diese Software umsonst daherkommt, ist mir der Preis, den ich mit den ständigen Rumbasteln bezahlen muss, zu hoch.
Da wäre es doch sinnvoll dies im Grafana oder/und Influx Forum zu posten.
ioBroker hat da keinen Einfluss auf 3rd Party Programme.
-
@homoran sagte in Raspberry Pi 4 startet nicht mehr:
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Auch wenn diese Software umsonst daherkommt, ist mir der Preis, den ich mit den ständigen Rumbasteln bezahlen muss, zu hoch.
Da wäre es doch sinnvoll dies im Grafana oder/und Influx Forum zu posten.
Sicherlich hast du recht.
Aber ich möchte nun auch keine Kampagne gegen InfluxDB, Grafana & Co. lostreten. Die Programme sind schon leistungsfähig. Ich habe mir halt nach all dem Frust einmal Luft machen müssen. Es sollte sich jeder selbst überlegen, ob er für die Entwickler den (kostenlosen) Betatester zu spielen bereit ist. Umsonst ist offenbar nichts im Leben.
Dank BackItUp und AppkePiBaker habe ich nach (nur) einem Tag wieder mein System am Laufen. Und nicht zu vergessen, die Hilfe hier im Forum.
-
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Es sollte sich jeder selbst überlegen, ob er für die Entwickler den (kostenlosen) Betatester zu spielen bereit ist.
Entschuldige, aber mir geht dieser Anspruch etwas gegen den Keks. Wenn man nicht bereit ist, den kostenlosen Betatester zu "spielen", darf man einfach nicht die allerneueste Version einsetzen. Ganz einfach. Welches QS-Team soll denn all die neuen Funktionen in allen möglichen Konstellationen durchtesten? Das ist Teil der Idee hinter Open Source: Geben und nehmen (und auch ab und zu mal die Dokumentation lesen).
Umsonst ist offenbar nichts im Leben.
Doch, die Lebenszeit der Entwickler, die auch du ein Stück weit für deine Zwecke nutzt. Und die der Leute, die dich hier supporten.
-
Wie ich oben schrieb, will ich daher auch keine Kampagne lostreten. Die Arbeit der Entwickler und all der Leute, die hier Hilfestellung leisten, kann man gar nicht hoch genug schätzen. Dennoch mein Fazit: Letztlich ist nie etwas ganz umsonst.
Aber die Sache, nicht immer die neuste Software zu verwenden, ist nicht so ganz einfach zu realisieren. Die meisten von uns dürften doch wohl ihr System via sudo apt update && sudo apt upgrade bei Bedarf aktualisieren. Damit bekommt man nolens volens natürlich stets die neuesten Versionen aller mittels apt verwalteten Software-Komponenten auf sein System gebügelt.
Vielleicht weißt du einen Weg, wie man hier geschickter vorgehen könnte?
-
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Damit bekommt man nolens volens natürlich stets die neuesten Versionen aller mittels apt verwalteten Software-Komponenten auf sein System gebügelt.
Es sei denn, man tackert eine bestimmte Version per 'apt-hold' fest.
Obacht, dadurch kann man sich dann allerdings Probleme mit nicht erfüllbaren Abhängigkeiten an anderer Stelle schaffen. Also je nachdem wie zentral das Paket im System sitzt. Bei Grafana wohl eher ein kleineres Risiko. -
Vielen Dank für deine - wie immer aufschlussreichen - Erläuterungen.
Wenn ich das recht überblicke, sollte ich als Otto Normalverbraucher dann doch besser bei sudo apt update && sudo apt upgrade bleiben.
Was einem so alles passieren kann, will man eine von BackItUp erstellte Sicherung in eine Neuinstallation von Grafana einspielen, habe ich in meiner Dokumentation zum Umzug auf einen Pi 5 ergänzt (s. Grafana wiederherstellen).
-
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Vielleicht weißt du einen Weg, wie man hier geschickter vorgehen könnte?
Da wird wohl jeder seinen eigenen Weg haben, der von den eigenen Ansprüchen und Fertigkeiten abhängt. Ich persönlich finde es für jemanden, der keine "Beta-Tests" machen möchte, ungeschickt, jedes Update mitzunehmen.
Zwischen "jeweils den neuesten heißen Scheiß installieren" und "ich lasse mein System versumpfen" wird es irgendwo im Bereich von einigen Wochen einen guten Update-Rhythmus geben.
Und wenn man sich doch mal einen Bug einfängt, sollte man den Weg zurück parat haben. Im Beispiel Grafana etwa so:
sudo apt update sudo apt install grafana=Version
Ersetze Version durch die gewünschte Version, z.B. grafana=12.2.0.
-
Was glaubst, was ich seit Jahren als Vorgehen pflege? Ich bin schon seit Langem dabei, oft erst dann zu aktualisieren, wenn man mir mit depricated droht.
Aber in dieser Ausnahmesituation hatte ich gar keine andere Wahl gesehen, als über apt install .. alles Nötige neu zu installieren.
Sei's d'rum! Die Katastrophe ist ausgestanden und meiner Dokumentation zum Umstieg auf eine Pi 5 ist ein Abschnitt Grafana wiederherstellen hinzugekommen.
-
@all
Unser Raspberry Pi 4 ging kaputt und mit ihm unsere gesamte hierauf aufbauende Hausautomatisierung.
Mein Vorgehen beim Totalausfall unseres Systems ..
- Ausbau der SSD aus dem defekten System
- Image der SSD mit ApplePiBaker
- Dieses Image mit ApplePiBaker auf eine SD übertragen
- Den neuen Pi 4 hiermit gestartet.
- Anbindung der Homematic Geräte über HB-RF-ETH korrigiert
- Anbindung der ZigBee-Geräte über COD.m korrigiert (einfach bloß IP ändern)
- Neuinstallation von Grafana und Backup mittels BackItUp (einfach bloß IP ändern)
Im letzten Punkt steckte die nächste Katastrophe: Grafana ließ sich nicht mehr starten und musste neu installiert werden.
Zum meinem Glück hatte ich auch für diesen Fall Vorsorge getroffen und konnte auf meine Dokumentation zu InfluxDB&Grafana zurückgreifen. Da sich auch hier wieder einiges verändert hat, habe ich dies gleich in meine Dokumentation zum Umstieg auf einen Pi 5 (Abschnitt Grafana wiederherstellen) eingefügt.
-
Katastrophe...
Größer haben wir es nicht?Das sind ganz normale Vorgänge und Entwicklungen da bei deiner 'Katastrophe'.
Ich bin schon seit Langem dabei, oft erst dann zu aktualisieren, wenn man mir mit depricated droht.
Das ist deutlich zu spät.
-
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Meine Lehren aus dem Totalausfall unserer Systems ..
Ausbau der SSD aus dem defekten System
Image der SSD mit ApplePiBakerDas ist doch schon der erste und größte Fehler.
Solche "Images" darf man allerhöchstens noch auf dem identischen System verwenden.Für jede andere Anwendung muss man mit Konfigurationsbackups und Neuinstallation arbeiten.
-
@homoran sagte in Raspberry Pi 4 startet nicht mehr:
@legro sagte in Raspberry Pi 4 startet nicht mehr:
Ausbau der SSD aus dem defekten System
Image der SSD mit ApplePiBakerDas ist doch schon der erste und größte Fehler.
Solche "Images" darf man allerhöchstens noch auf dem identischen System verwenden.Pardon! So ein Quatsch!
Die Software des Systems sollte - und war - durch den Ausfall der Netzelektronik nicht beschädigt. Die Sendemodule für ZigBee und Homematic liegen im LAN, das Ersatzgerät ist identisch mit dem defekten. Das Ganze schreit geradezu nach dem hier vorgestellten Vorgehen. Darüber hinaus hat sich das Zusammenspiel von BackItUp und ApplePiBaker glänzend bewährt.
-
@thomas-braun sagte in Raspberry Pi 4 startet nicht mehr:
Katastrophe...
Größer haben wir es nicht?Für mich war das ein GAU. Während meines Berufslebens ist so ein Totalausfall in meinem Verantwortungsbereich nie vorgekommen. Ich hatte stets alle Systeme redundant ausgelegt. Hier wüsste ich (noch) gar nicht, wie ich das machen könnte.
Da hier im Forum sicherlich auch Leute wie unsereiner sich tummeln, sollte meine Zusammenfassung dennoch nicht umsonst sein, auch wenn einige von mir verwendeten Vokabeln dem ein oder anderen missfallen.