Dreamboard

Sven H · 31. Juli 2018

Hallo

Ich nutze beim Programmieren sehr oft das Telnet-Live-Log (journalctl -f -u enigma2)
Allerdings stören dabei dann immer die anderen "normalen" Log-Ausgaben.

Kann man den Telnet-Befehl für das Live-Log irgendwie ergänzen, um die log-Ausgabe auf bestimmte Einträge zu filtern?
Wenn ich z.B. in einem Plugin ein print "=== test123..." einbaue, würde ich das live-Log gern auf solche Einträge beschränken wollen, die mit "=== test123" beginnen.

Ist sowas möglich ?
Oder könnte man die Log-Ausgabe auf ein bestimmtes Plugin begrenzen ?

Im Nachhinein geht das ja mit journalctl und grep, aber ich hätte da gern eine gefilterte Live-Ausgabe.

dre · 31. Juli 2018

Du kannst imho nur auf units einschränken. Und plugins laufen unter enigma2

Sven H · 31. Juli 2018

Schade.
Das war auch das Ergebnis meiner bisherigen Recherchen
Hatte gehofft, dass es da vielleicht doch noch was gibt.

Fred Bogus Trumper · 31. Juli 2018

das könnte funktionieren:

Code

journalctl -f -u enigma2|grep "=== test123..."

dann sollte der der log nur die Events ausspucken, die den string "=== test123..." beinhalten

so nur die Zeilen die mit "=== test123..." mit beginnen

Code

journalctl -f -u enigma2|grep "^=== test123..."

wenn das " Bestandteil des Strings ist

Code

journalctl -f -u enigma2|grep '^"=== test123..."'

alpha · 31. Juli 2018

muessste doch so gehen: "journalctl -f -u enigma2| grep "=======test123"
edit: zu langsam

Sven H · 31. Juli 2018

Danke euch Beiden

Die 1. Variante funktioniert tatsächlich
Das wird mir zukünftig einiges leichter machen.
Ich dachte, ich hätte diese Sache auch schon mal probiert. Da hat dann bestimmt was anderes wieder nicht gepasst.
Das passiert mir wohl öfter, weshalb ich froh bin, dass man hier dann doch die passende Hilfe bekommt

Die 2. Variante mit dem ^ klappt komischerweise nicht, wobei ich gerade gedacht hätte, dass dies die Lösung sein wird, da man ja nur den Beginn-Text vorgeben kann.

Aber egal, mit Variante 1 geht es ja (auch mit dem Beginntext)

Fred Bogus Trumper · 31. Juli 2018

man müsste das auch auf den Plugin Namen beschränken können und die Verwendung von mehrfach Suchkritieren ist auch möglich - durch trennen mit \|

z.B. so: spuckt nur Events aus die entweder mit === test123... beginnen oder EMC beinhalten, Mehrfachkomination auch möglich

Code

journalctl -f -u enigma2|grep "^=== test123...\|EMC"

Ich bin zu wenig in Python bewandert, deshalb weiß ich nicht ob die Klasse etc. des Plugins angegeben werden muss, jedenfalls spuckt der log so nur EMC events aus:

Code

root@dm900uhd:~# journalctl -f -u enigma2|grep "^=== test123...\|EMC"
Jul 31 22:16:16 dm900uhd enigma2[261]: action ->  PluginMovieSelectionActions EMCEXIT
Jul 31 22:16:16 dm900uhd enigma2[261]: [EMCMovieSelection] cancelThreadMsg
Jul 31 22:16:16 dm900uhd enigma2[261]: EMC: resetInfo

\\Edit
man kann das Gefilterte auch noch mal Filtern

sucht nach den Strings "=== test123..." am Zeilenanfang und "EMC" (egal wo in der Zeile), spuckt aber nur die Zeilen aus, die den String "ERROR" beinhalten, aber nicht den String "foo"

Code

journalctl -f -u enigma2|grep "^=== test123...\|EMC"|grep ERROR|grep -v foo

man grep hilft da gut weiter

Sven H · 31. Juli 2018

Vielen Dank.
Jetzt ärgere ich mich gerade, dass ich die Frage nicht schon eher gestellt habe.

Das mit dem ^ klappt vermutlich nicht, weil vor dem Text ja noch die Zeitausgabe + Box + enigma2 steht.
Die wird da ja beim grep mit geprüft

Fred Bogus Trumper · 31. Juli 2018

genau

grep "^STRING" sucht nach dem STRING am Zeilenanfang, grep "STRING" such die gesamte Zeile nach dem Vorkommen ab, grep "STRING$" sucht den STRING am Ende der Zeile und spuckt die aus.

einfach mal "grep" bzw. "egrep" googeln, da findet man genügend Beispiele und hints wie man logs bzw. files mit grep durch die Pipe jagt - wobei ich egrep im DreamOS noch nicht getestet habe, grep sollte in dem Fall aber ausreichen

dhwz · 1. August 2018

@Sven H
Du solltest da mal ein -o cat anhängen an das journalctl, dann sind auch die unnötigen Datumsstempel + Boxenname + Prozess weg
Hab das noch nie ohne gestartet das nervt doch, ok bei mir heißt "journalctl -f -u enigma2 -o cat" auch schon immer e2log als alias

Sven H · 1. August 2018

Das ist auch gut
Dann dürfte das auch wieder mit dem ^ funktionieren.

Mir ist aber aufgefallen, dass bei mehreren "grep"-Anweisungen das log irgendwie sehr träge reagiert und teilweise Ausgaben verschluckt.

Soweit ich die Anweisung einfach halte, klappt das ganz gut.
Zum Verknüpfen von 2 Texten verwende ich daher jetzt grep "text1.*text2" anstelle von grep "text1" | grep "text2"
(Also wenn beide Texte in der Zeile vorkommen sollen)

dhwz · 1. August 2018

nimm einfach einen regex dann musst du auch nicht 2x grep verwenden und kannst x Begriffe filtern

Fred Bogus Trumper · 1. August 2018

klar, du filterst ja den live log, d.h. die nächste Ausgabe kommt erst, wenn du wieder eine Taste auf der FB drückst die sich auf den Filter auswirkt

Aber deine Filter sind aber zwei paar Schuhe!

grep "text1" | grep "text2"
sucht zuerst nach dem string "text1" und dann im Ergebnis nach "text2", d.h. es werden nur die Zeilen ausgespuckt die beide strings enthalten - die Reihenfolge ist dabei egal

grep "text1.*text2"
wirft nur Zeilen aus, in denen der string "text1" vor dem string "text2" vorkommt, aber nicht die Zeilen, die denen der string "text2" vor dem string "text1" vorkommt, d.h. du erhälst u.U. zwei verschieden Ergebnisse ...

Eine Alternative zu grep "text1" | grep "text2" wäre noch

grep "text1\|text2"

das spuckt alle Zeilen aus, in der zumindest ein String einmal vorkommt und liefert u.U. auch wieder ein anderes Ergebnis als die beiden ersten Varianten

jetzt kommt es eben darauf an, welches Ergebnis du haben willst bzw. welche Bedingungen erfüllt werden sollen

Sven H · 1. August 2018

Zitat von Fred Bogus Trumper

klar, du filterst ja den live log, d.h. die nächste Ausgabe kommt erst, wenn du wieder eine Taste auf der FB drückst die sich auf den Filter auswirkt

Naja, wenn ich 2 grep drin habe, dann kommen die Logausgaben teilweise erst 3-4 Sekunden nach dem Drücken der Taste oder manchmal gar nicht. Bei nur einem grep gehts sofort.

Ist jetzt aber kein Problem, da ich ja für mich eine grundlegende Lösung gefunden habe

Ja, das mit ".*" ist etwas anders als 2 einzelne greps, aber für mich passend/ausreichend, um auf bestimmte Logausgaben zu filtern.

Hatte ja beim PTS viel über das log analysieren müssen.
Da haben natürlich die vielen anderen zusätzlichen Logausgaben gestört.
Mit dem jetzigen Wissen, wäre das deutlich einfacher gewesen
Das nutze ich dann beim nächsten Projekt