Logfile-Übersetzer

[kanzlerleuk]

Obwohl meine RaspberryMatic gut läuft, habe ich mal in das Logfile /var/log/messages geschaut. Leider ist das für mich relativ nichtssagend. Gibt es irgendwo eine Schlüsselliste oder Hinweise, wie man das interpretieren kann? Habe mal einen Auszug der mich interessierenden Sachen beigefügt.
VG
Thomas

Logfile.pdf

(46.72 KiB) 106-mal heruntergeladen

[jmaus]

Ah, der nächste Logfileleser. Langsam muss ich echt überlegen einfach den syslog so zu "tunen" das keinerlei Logmeldungen mehr ausgegeben werden. Es gibt wirklich zu viele die einfach wohl in beamten art-und-weise täglich ihre Logfiles studieren als wäre es die Tageszeitung.

Ich kann nur noch einmal betonen: Es ist VOLLKOMMEN normal das ein Syslog Meldungen beinhaltet (auch Fehlermeldungen). Jetzt aber zu versuchen sein Logfile auf 0 bytes zu optimieren ist nicht im sinne des Erfinders. Die Vorgehensweise sollte in diesem Falle immer Fehlergetrieben sein. D.h. wenn ein Fehler auftritt schaut man ins Logfile um zu schauen ob es an der Stelle des Fehler eine Ausgabe gibt. Und nicht anders herum.

[Janniman]

Moin Jens,

so langsam platzt mir etwas die Hutschnur!
Das du eventuell Logfileleser verteufelst ist ja ok, aber behalte dies doch bitte für dich, wenn du nicht helfen willst.

Wenn User sich den Logfile ansehen, denn dafür ist er ja da, dann hat das meist einen Grund. Für mich ist der Logfile schon deshalb interessant, weil ich so sehen kann, die CCU3 telefoniert exakt alle 5 Minuten nach Hause. Das alleine ist schon nicht ok, aber wenn man auf "nur Fehler" logt und trotzdem das Logfile zugemüllt wird (wie gesagt: andauerndes Schreiben auf die SD-Karte, Angreifbarkeit, etc.), dann ist das ein derber Fehler der Programmierung, NICHT des Nutzers.

Das ein Logfile lesbar ist verlangt niemand (ich zumindest), aber irgendwie interpretierbar (Codes, Liste, Wiki,...) wäre trotzdem toll.

Wenn, wie bei mir, ein Temperatur-Differenz-Sensor gute Batterien anzeigt, dazu gleichmäßig immer aktuell seine Daten sendet, aber die Servicemeldungen über angebliche Kommunikationsprobleme trotzdem nicht gelöscht werden können (warum nicht?), dann liegt irgendwo ein Fehler vor. Wo guckt denn da ein Nutzer dann nach, wenn nicht eventuell mal in den Logfile?

Scheiß CCU3, ich hänge jetzt mehr und länger vor dem blöden Ding, als mit der langsameren CCU2...

Jan

[jmaus]

so langsam platzt mir etwas die Hutschnur!
Das du eventuell Logfileleser verteufelst ist ja ok, aber behalte dies doch bitte für dich, wenn du nicht helfen willst.

Tut mir leid wenn du dich angegriffen füllst. Ich kann es nur langsam nicht mehr sehen das einige hier anscheinend nicht Problemgetrieben vorgehen sondern vermeintliche Probleme suchen wo keine Probleme sind.

Wenn User sich den Logfile ansehen, denn dafür ist er ja da, dann hat das meist einen Grund. Für mich ist der Logfile schon deshalb interessant, weil ich so sehen kann, die CCU3 telefoniert exakt alle 5 Minuten nach Hause. Das alleine ist schon nicht ok, aber wenn man auf "nur Fehler" logt und trotzdem das Logfile zugemüllt wird (wie gesagt: andauerndes Schreiben auf die SD-Karte, Angreifbarkeit, etc.), dann ist das ein derber Fehler der Programmierung, NICHT des Nutzers.

Immer dieses Argument von wegen "Logfile zugemüllt". Wo steht denn geschrieben das ein Logfile leer sein muss oder das man da nicht 1000 eintrage in der minute reinladen lassen darf? Am Schluss ist ein Logfile dazu da gefiltert zu werden. D.h. wenn man ein Problem hat schaut man da rein, benutzt ein filter (z.B. 'grep' oder eine extra Logfile-Filtersoftware) und sucht auf das Problem passende Logfileeinträge. Und wenn dir ein Logfile zu groß ist und du es als "zugemüllt" empfindest, dann nutze solche filterungsmethoden eben. Das sollte die bessere Herangehensweise sein als zu erwarten das ein Logfile komplett leer sein muss wenn es keine erkennbaren Probleme gibt.

Und übrigens, es gibt da kein andauerndes Schreiben auf die SD-Karte. Bei einer CCU/RaspberryMatic werden Logfiles in ein tmpfs geschrieben welche im RAM liegt und bei einem Neustart folgerichtig im Nirvana landet. D.h. da wird nichts auf die SD-Karte geschrieben und das ist mit Absicht so.

Das ein Logfile lesbar ist verlangt niemand (ich zumindest), aber irgendwie interpretierbar (Codes, Liste, Wiki,...) wäre trotzdem toll.

Hast du schon einmal in einen Windows Eventlog geschaut? Und hast du da schonmal die Dokumentation der einzelnen Einträge angeschaut? Und war das Hilfreich? Ganz sicher nicht. Der Anspruch kann hier wirklich nicht sein das man jetzt gar eine Dokumentation anfängt für Logfileeinträge und das von der technischen Sprache in die allgemeine Sprache übersetzt die jedermann verstehen muss. Sowas kann niemals funktionieren. Noch einmal, *wenn* es ein problem gibt schaut man da rein und versucht einträge die auf das Problem passen könnten rauszufiltern und wenn man die gefunden hat dann geht man auf den Entwickler/Hersteller zu und übergibt ihm das als Information.

Wenn, wie bei mir, ein Temperatur-Differenz-Sensor gute Batterien anzeigt, dazu gleichmäßig immer aktuell seine Daten sendet, aber die Servicemeldungen über angebliche Kommunikationsprobleme trotzdem nicht gelöscht werden können (warum nicht?), dann liegt irgendwo ein Fehler vor. Wo guckt denn da ein Nutzer dann nach, wenn nicht eventuell mal in den Logfile?

Das stimmt, in einem solchen Fall kann und soll er da nachschauen. Er sollte hierbei aber nicht den Anspruch haben alles da drin zu verstehen was da so geschrieben steht. Denn die Meldungen die da rausgeschrieben werden sind vom Entwickler so platziert worden das vor allem ER diese verstehen kann. Und man sollte beim betrachten eben auch nicht den Anspruch haben ein komplett leeres Logfile zu haben wenn es keine erkennbaren Fehler gibt.

[HMNutzer]

Servus Jan,

in einem Forum und einem Produkt, das Jens in seiner Freizeit kostenlos betreut bzw. entwickelt sind manche Formulierungen überdenkenswert.

[Janniman]

Bitte nur ein einziges Beispiel!?

Jan

[Samhain]

Servus Jan,

in einem Forum und einem Produkt, das Jens in seiner Freizeit kostenlos betreut bzw. entwickelt sind manche Formulierungen überdenkenswert.

Sehe ich genauso. Schaut doch mal in ein laufende Windows oder in ein MacOS Log . Da ist es auch nicht anders ... und wen interessiert es da? ... keine Sa*

[nicolas-eric]

Jens hat recht, es ist bei ALLEN Systemen ganz normal, dass hin und wieder im Logfile etwas auftaucht.
Das kann man komplett ignorieren, denn es wirkt sich ja nicht auf das laufende System auf und es gibt keinen Fehler.
Genau wie er sagt, wird andersherum ein Schuh draus.
Wenn mal Ewas nicht läuft, nimmt man das Logfile zur Hilfe.
Solange es keine Probleme gibt, lässt man das Logfile Logfile sein und freut sich über sein funktionierendes Spielzeug.

Obwohl ich zugeben muss...das ist eh schon viel viel besser geworden.
Seit der Installation der aktuellen RM vor etwas über 4 Tagen (ein paar Minuten nachdem Jens das hier gepostet hatte) habe ich keine einzige Fehlermeldung im Log!

...ausser bei Alchys Servicemeldung Script...da wird wohl mal die aktuelle Version des Scripts fällig, ich hab noch 1.60, was komischerweise im entsprechenden Thema ausgestrichen ist...das wird wohl einen Grund haben...

[alchy]

in einem Forum und einem Produkt, das Jens in seiner Freizeit kostenlos betreut bzw. entwickelt sind manche Formulierungen überdenkenswert.

So, welche denn?
Was darf man denn deiner Meinung noch sagen? oder was nicht?
Stell mal bitte eine umfassende Liste auf.
Das nageln wir dann an die Forumbenutzerrichtlinien zum Akzeptieren beim Einloggen ins Forum.
Ich wusste auch gar nicht, das es sich bei dem Forum hier um ein reines RaspberryMatic Forum handelt.

Sehe ich genauso.

Ohje, die "UmjedenPreisJubler" und sich nur bückend schleichend bewegenden Gutmenschen mit Scheuklappen sind wieder los.
Wie das endet, wenn man nichts mehr fragen darf, hat die Geschichte mehrmals gezeigt.
Wenn dich Logs nicht interessieren dann lass es doch sein. Hoffentlich merken sich die Helfer hier im Forum eine solche Aussage und reagieren bei deinen Anfragen entsprechend.

Klar überbewerten sollte man nie irgendetwas. Ein Error im Fehlerprotokoll ist aber trotzdem ein Error, auch wenn man hier immer wieder behauptet "ignorieren" ist auch gut. Ist da ein Problem? Nein nicht in jedem Fall. Wie viele Bugs sind schon gefunden wurden, weil das Logfile benutzt wurde?

Fakt ist, auf nur Fehler hat das Fehlerprotokoll meiner CCU2 ab 10min nach Neustart leer zu sein.
Und wenn es trotzdem Fehler Fehler enthält, dann weiß ich warum.


Alchy

[hoedlmoser]

Obwohl meine RaspberryMatic gut läuft, habe ich mal in das Logfile /var/log/messages geschaut. Leider ist das für mich relativ nichtssagend.

dann sollte hier Deine persönliche google recherche starten und Du wirst eine sehr steile lernkurve haben.

Gibt es irgendwo eine Schlüsselliste oder Hinweise, wie man das interpretieren kann?

nein, ein kochrezept gibt es hier keines. Du solltest Dich zuerst mit syslog an sich beschäftigen und dann mit den einzelnen daemons, die hier die logmeldungen werfen. verschärfend bei der /var/log/messages auf der CUU kommt hinzu, daß da einfach alles reingepackt wird, unabhängig von den einstellungen auf der GUI (wobei, ich hab die syslog.conf auf der CCU selbst nicht gefunden).

nur so viel, der aufbau ist in etwa wie folgt: datum und uhrzeit, hostname, priority als facility.level, daemon [mit prozess ID], eigentliches blabla.

Habe mal einen Auszug der mich interessierenden Sachen beigefügt.

zum einen verstehe ich den Jens, daß er sich als hauptentwickler der RaspberryMatic hier nicht mit einer recherche zu für einen (linux) anfänger als dubios aussehenden logmeldungen hinreissen lassen will.

ich verstehe aber alle anderen nicht, die nichtmal im ansatz versuchen die log meldungen zu analysieren, und sich stattdessen damit aufhalten, ob man jetzt vielleicht doch in die logfiles reinsehen soll, will, muß, ... und was man hier nun an persönlicher meinung sagen darf oder nicht.

dann mach ich hier mal den anfang:

Code: Alles auswählen

Sep 24 19:11:06 RaspberryMatic local0.err ReGaHss: Error: IseESP::ScriptRuntimeError: !# variables.fn 1.4 CCU.IO !# !# Dieses Script gibt die Systemvariablen als JSON String aus !# !# 3'2013‐7'2013 hobbyquaker https://github.com/hobbyquaker

da hauts irgendein script auf die nase "ScriptRuntimeError".
nachfolgend sieht das nach dem inhalt des scripts aus, und da stehen ein paar weiterführende hints drinnen, wir werfen mal "variables.fn 1.4 CCU.IO" in eine suchmaschine, dabei dürfte es sich um den scriptnamen handeln. das führt uns dann nach ein paar links zu https://github.com/hobbyquaker/ccu.io/b ... riables.fn und wir lesen, daß dieses projekt seit 2015 deprecated ist. vielleicht ist das die ursache, warum das script auf einen fehler läuft?

Code: Alles auswählen

Sep 24 20:28:07 RaspberryMatic user.err rfd: Can't remove device remotely

hierzu hätte mich die suchmaschine zu viewtopic.php?f=26&t=19439&start=20#p266148 geleitet. hast Du ein LAN-gateway im einsatz?

Code: Alles auswählen

Sep 25 04:13:50 RaspberryMatic daemon.info ntpd[426]: Listen normally on 11 eth0 [2001:16b8:555f:a900:ba27:ebff:fe2f:e6b9]:123 
Sep 25 06:13:49 RaspberryMatic daemon.info ntpd[426]: Deleting interface #10 eth0, 2001:16b8:5528:f900:ba27:ebff:fe2f:e6b9#123, interface stats: received=0, sent=0, dropped=0, active_time=93528 secs 

der ntpd ist für die zeitsynchronisation zuständig. zusätzlich hast Du hier IPv6 im einsatz (erkennbar an der IP adresse mit den doppelpunkten). manche ISPs teilen ihren kundenanschlüssen gerne alle x stunden neue IPv6 prefixe zu, das nennt man dann DHCPv6-PD (Prefix Delegation), erkennbar bei Dir wie folgt.

• 2001:16b8:555f:a900:ba27:ebff:fe2f:e6b9
• 2001:16b8:5528:f900:ba27:ebff:fe2f:e6b9

Du bekommst also wie es scheint alle 24 stunden einen neuen prefix. damit die alten verbindungen nicht sofort abschnappen, bleibt das alte prefix noch zwei stunden aktiv und erst dann wird die alte IPv6 adresse vom interface gelöscht (auch erkennbar an "active_time=93528 secs", das entspricht knapp 26 stunden, also 24 + 2 stunden).

übrigens, diese logmeldung hat prio info. kann also gefließentlich ignoriert werden.

Code: Alles auswählen

Sep 25 09:07:18 RaspberryMatic daemon.info cuxd[516]: save  paramsets(/usr/local/addons/cuxd/cuxd.ps) size:848

diese logmeldung hat auch prio info. und die suchmaschine bringt mich zu viewtopic.php?f=37&t=37037#p360661 also alles ganz normal, der CUxD will nur mal seine config wegsichern, damit er sie nicht vergisst.

ich hab also mal die suchmaschine für Dich gemacht, das kannst Du bei der nächsten Dich interessierenden logmeldung sicher auch selbst und kommst dann mit spezifischen fragen hier wieder an.