Fehlende Option bei tail in RM

[Xel66]

Hallo Forum,

ich benötige mal Schwarmwissen. Ich möchte mit der Zeile

Code: Alles auswählen

system.Exec("tail --follow=name --retry /var/log/messages  | awk '/ReGaHss: Info: Program/ { print $0 }' >> /var/log/run-prog.log &"); 

die Systemlogdatei (messages) auf Programmaufrufe (Suchstring "ReGaHss: Info: Program") überwachen und in eine separate Logdatei (run-prog.log) schreiben. Einfach nur, um die Tätigkeiten des Systems besser im Aufge behalten zu können, ohnd die Logdatei manuell durchsuchen zu müssen. Da ich meinen Loglevel recht hochgedreht habe, wird die messages-Datei zyklisch über das Logrotate zur messages.0 und später gepackt. Dieser Aufruf oben funktioniert aber nicht. Die Optionen --follow=name und --retry scheinen in der buildroot-Basis der Raspberrymatic nicht implementiert zu sein.

Einen funktionierenden Aufruf bekomme ich mit

Code: Alles auswählen

system.Exec("tail -f /var/log/messages  | awk '/ReGaHss: Info: Program/ { print $0 }' >> /var/log/run-prog.log &"); 

hin. Das läuft, bis eine neue messages angelegt wird (file discriptor ändert sich dann, darum will ich auf "name" binden). Dann werden keine neuen Logeinträge mehr in die run-prog.log geschrieben. Laut manchen Anleitungen im Neuland sollte aber auch die Option -f dem von mir gewünchten --follow=name --retry entsprechen. Habe ich irgendwas übersehen? Ist irgendwas an meiner Syntax falsch oder fehlen einfach nur die in anderen Systemen vorhandenen Optionen --follow und --retry?

Gruß Xel66

[jmaus]

Ist irgendwas an meiner Syntax falsch oder fehlen einfach nur die in anderen Systemen vorhandenen Optionen --follow und --retry?

Nun, das was du festgestellt hast ist eben der Unterschied zwischen einem minimalistischen Buildroot/BusyBox basiertem System und einem full-fledged Linux System welches gewisse standardbefehle wie ls aber eben auch tail aus anderen Quellen bezieht. Schau dir einfach mal was die versionsausgaben der beiden Befehle unter RaspberryMatic vs Ubuntu ausgibt:

RaspberryMatic:

Code: Alles auswählen

:~# tail -h
tail: invalid option -- 'h'
BusyBox v1.36.1 (2024-04-17 01:38:10 UTC) multi-call binary.

Ubuntu:

Code: Alles auswählen

$ tail --version
tail (GNU coreutils) 8.32

Und dann kannst du unter Ubuntu via "man tail" mal die manual page mit der der busybox version von "tail" vergleichen und wirst feststellen, das es da eben das "--follow" nicht gibt. Hoffe damit klärt warum es da unterschiede gibt.

Abgesehen davon halte ich aber die Nutzung von solch einer Dauerüberwachung via system.Exec() und tail, etc. bzw. dem dauerhaften parsen von Logfiles von seiten der Stabilität keine wirklich gute/nachhaltige Idee. Besser du baust dir dafür extra dienste / shell-skripte die du direkt unter dem Linux-System von RasberryMatic beim start starten lässt (z.b. via der verschiedenen rc-startup skripte) um das gleiche – aber eben unabhängig der ReGaHss Skriptengine – zu erreichen.

[Baxxy]

OT:
Manchmal ist das schon unschön das einige Tools in RM so "abgespeckt" sind, ist mir vor kurzem auch bei top aufgefallen als ich mal top -p nutzen wollte.

Kann man sich die Tools eigentlich "als Vollversion" selbst kompilieren?

[Xel66]

Nun, das was du festgestellt hast ist eben der Unterschied zwischen einem minimalistischen Buildroot/BusyBox basiertem System und einem full-fledged Linux System ...

OK, daran liegt es dann wohl. Thx. Dass das System abgespeckt ist, war mir bewusst, aber dass sich vorhandene Optionen (-f) anders verhalten, irritiert mich. Egal, muss ich mal schauen. Meine andere Lösung, die den Zugriff auf den Webserver überwacht, läuft dauerhaft. Aber dort läuft das Logging auch anders.

Abgesehen davon halte ich aber die Nutzung von solch einer Dauerüberwachung via system.Exec() und tail, etc. bzw. dem dauerhaften parsen von Logfiles von seiten der Stabilität keine wirklich gute/nachhaltige Idee.

Naja, system.Exec() nutze ich ja nur für das einmalige Starten von tail. Danach läuft es im Hintergrund (&). Ich sähe jetzt keinen Unterschied, ob ich diesen Aufruf einmalig per system.Exec() oder per Shell-Script auf dem System direkt mache. Es fällt mir via WebUI und Aufruf per Script nur einfacher, weil ich zwar die WebUI remote über den Dientleister erreiche, aber eben nicht die Systemebene (Konsole).

Gruß Xel66

[ejdv]

Dieser Aufruf oben funktioniert aber nicht. Die Optionen --follow=name und --retry scheinen in der buildroot-Basis der Raspberrymatic nicht implementiert zu sein.

Einen funktionierenden Aufruf bekomme ich mit .. hin. Das läuft, bis eine neue messages angelegt wird (file discriptor ändert sich dann, darum will ich auf "name" binden). Dann werden keine neuen Logeinträge mehr in die run-prog.log geschrieben.

Versuche es mal mit „tail -F“.
Das sollte gleich sein mit „—follow“ plus „—retry“.
Manchmal macht „-f“ das gleiche wie „-F“, aber nicht immer.

[jmaus]

Manchmal ist das schon unschön das einige Tools in RM so "abgespeckt" sind, ist mir vor kurzem auch bei top aufgefallen als ich mal top -p nutzen wollte.

Kann man sich die Tools eigentlich "als Vollversion" selbst kompilieren?

Können kann man prinzipiell alles, klar. Die Frage ist nur ob das Sinn ergibt. RaspberryMatic bzw. eine CCU ist eben ein embedded System wo die Priorität in Stabilität, Leichtgewichtigkeit usw. liegen sollte und nicht im Funktionumfang. Aber ja, ich könnte natürlich auch coreutils mit aufnehmen und python und htop und und und... aber dann wäre es kein leichtgewichtiges System eben...

[Baxxy]

Natürlich möchte ich nicht das RM unnötig aufgebläht wird.
Otto-Normal-User braucht das alles ja auch nicht.

Aber manchmal, speziell zu Debugging-Zwecken und wenn's ans Eingemachte geht wären "Vollversionen der Tools" nicht verkehrt.
Vor allem da sich quasi alle Tipps, Anleitungen und ManPages im I-net nicht auf abgespeckte BuildRoot - Versionen beziehen.

Da kommt mir doch glatt eine Idee...
Ich wünsche mir ein "Dev-Kit-AddOn", also quasi ein aufgebohrtes hm-tools.

[jmaus]

Da kommt mir doch glatt eine Idee...
Ich wünsche mir ein "Dev-Kit-AddOn", also quasi ein aufgebohrtes hm-tools.

"hm-tools" wollte ich auch gerade schon erwähnen. Am besten äußerst du da deine Wünsche und dann können da diese tools ggf. mit aufgenommen werden die du brauchst.

[Xel66]

Versuche es mal mit „tail -F“.

Thx. Ich habe es jetzt mal so laufen. Meine aber, dass ich das schon mal so hatte. Ein anderes Log überwache ich schon mit der Option "-F". Gebe dann Rückmeldung.
EDIT (02:36): Bis jetzt scheint es zu funktionieren. Die messages wurde innerhalb der letzten drei Stunden schon mehrmals neu erstellt. Sollte sich das noch ändern, würde ich noch mal Rückmeldung geben. Danke noch mal.

Der Grund für mein Bemühen übrigens ist, dass ich mir zur Fehleranalyse diverse Logdateien per Mail zusenden lasse, wenn z.B. der DC ungewöhnlich hochgeht. Im messages(.0)-Log ist aber in solchen Fälle meist ein zu kleiner Zeitbereich enthalten (ja, ich logge zu detailliert ), wenn viel im System los ist (z.B. wenn alle Thermostate den Betriebsmodus wechseln). In dem Falle hilft eben auch kein gefilterter Auszug (mache ich mit "cat /var/log/messages | grep 'TX'" z.B. für die letzten Sendevorgänge). Da wäre eben eine etwas längere Historie der Programmläufe recht hilfreich.

Habe zwar einen Loghost auf einem NAS laufen, aber auch da sind die vorhandenen Filtermöglichkeiten unkomfortabel zu bedienen. Das tue ich mir wirklich nur an, wenn es unbedingt sein muss. Daher der "einfache" Weg mit dem via tail vorgefilterten separaten Log. Und vor allem, ich komme remote ohne Klimmzüge an die WebUI und - via CUxD - an das Log zur Ansicht dran. Häufig ist für mich kein Zugriff per VPN sondern nur über den bekannten Dienstleister auf die WebUI der CCU möglich.

Gruß Xel66