[Info] Volatile Protokollierung mit AVM-Bordmitteln

PeterPawn · 8 Jun 2015

Oft stellt man in eigenen Skripten ja fest, daß es schon schön wäre, wenn man einige Informationen nur für eine gewisse Zeit festhalten könnte, damit man bei Problemen auf diese Informationen zurückgreifen kann. Tritt kein Problem auf, interessieren diese Daten eigentlich nicht weiter.

Ein Schreiben solcher Daten ins Syslog macht dieses Protokoll schnell unübersichtlich, wenn es sich z.B. um das Protokollieren von irgendwelchen Zuständen im Fünf-Sekunden-Takt handelt und auch das Schreiben in eine eigene Datei, die man dann auf eine passende Anzahl von Zeilen begrenzt (mit wc -l und entsprechendem Kürzen der Datei, wenn die gewünschte Zeilenanzahl überschritten ist), ist zwar eine mögliche Lösung, aber bei variabler Zeilenlänge kann man auch nie exakt sagen, wieviel Platz solch eine Datei am Ende benötigt ... außerdem ist der Aufwand für eine solche Lösung (sowohl beim Schreiben des Skripts als auch zur Ausführungszeit) recht hoch.

Solange die protokollierten Daten volatil sind, hat sich in der Programmierung für solche Zwecke eigentlich ein Ringpuffer eingebürgert. Das ist am Ende nur eine Datenstruktur fester Länge, in der man an der nächsten "freien" Stelle einfach seine Daten hinterlegt und den Zeiger auf diese freie Stelle anschließend so ändert, daß er hinter die neu gespeicherten Daten zeigt - damit dort der nächste Eintrag abgelegt werden kann. Wird das Ende des reservierten Platzes erreicht, beginnt die Speicherung wieder am Beginn der Struktur und überschreibt somit die ältesten Einträge.

AVM stellt mit der originalen Firmware eine sehr einfache Methode zur Verfügung, wie man so einen Ringpuffer in Gestalt einer Datei realisieren kann. Ich würde vermuten, daß dieses Prinzip bei AVM mit dem Eventlog irgendwann einmal begann, inzwischen nutzen mehrere AVM-Komponenten (voipd, multid) dieses Prinzip.

Mit dem Kommando "showshringbuf protocol" kann man einerseits die Daten im Ringpuffer in eine lesbare Form bringen (das Datum und die Uhrzeit werden automatisch zu jedem Eintrag im Buffer gespeichert) und andererseits kann man dieses Kommando auch problemlos einsetzen, um in einen eigenen Ringpuffer zu schreiben. Wenn man mit dem AVM-Kommando versucht in ein nicht existierendes Protokoll zu schreiben, wird automatisch eine Pufferdatei mit einer Größe von 8 KByte angelegt. Das kann ja durchaus ausreichend sein, andererseits ist das selbst AVM (z.B. beim voipd) zu wenig und so muß es ja auch noch eine Möglichkeit geben, eine etwas größere Datei zu verwenden.

Dazu muß man tatsächlich nur eine Datei passender Größe im Pfad /var der FRITZ!Box mit einem entsprechenden Namen anlegen, diese Ringpufferdateien folgen mit ihren Namen dem Schema "/var/.srb_protocol":

Code:

root@FB7490:~ $ dd if=/dev/zero of=/var/.srb_mylog bs=1024 count=32
32+0 records in
32+0 records out
32768 bytes (32.0KB) copied, 0.000740 seconds, 42.2MB/s
root@FB7490:~ $ ls -la /var/.srb_mylog
-rw-rw----    1 root     root         32768 Jun  8 18:16 /var/.srb_mylog

Damit wird ein neuer Ringpuffer für das Protokoll mit dem Namen "mylog" und einer Größe von 32 KByte angelegt. In dieses Protokoll kann man jetzt seine eigenen Daten schreiben, die Datenstruktur wird automatisch initialisiert:

Code:

root@FB7490:~ $ echo "New ring buffer log created" | showshringbuf -i mylog
root@FB7490:~ $ showshringbuf mylog
2015-06-08 18:18:23.888 - New ring buffer log created

Der Aufruf mit Option "-i" schreibt den Inhalt der Standardeingabe in den Ringpuffer, für jede Zeile der Eingabe wird ein Eintrag erzeugt. Auslesen läßt sich der Inhalt mit dem zweiten o.a. Kommando.

Jetzt hat diese Datei allerdings ein Problem ... beim Initialisieren der Dateistrukturen wird die Länge der Datei nicht richtig berücksichtigt. Wir schauen uns mal die hexadezimale Darstellung einer frisch erzeugten Datei an (die AVM-Busybox enthält kein hexdump-Applet, also braucht man eine eigene dafür - also nur zum Ansehen in diesem Falle):

Code:

root@FB7490:~ $ dd if=/dev/zero of=/var/.srb_mylog bs=1024 count=32
32+0 records in
32+0 records out
32768 bytes (32.0KB) copied, 0.000732 seconds, 42.7MB/s
root@FB7490:~ $ ls -la /var/.srb_mylog
-rw-rw----    1 root     root         32768 Jun  8 19:44 /var/.srb_mylog
root@FB7490:~ $ hexdump /var/.srb_mylog
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00008000

Das ist erst einmal nicht unerwartet, in der Datei stehen ausschließlich binäre Nullen. Nachdem wir die ersten Daten hineingeschrieben haben, sieht das schon etwas anders aus:

Code:

root@FB7490:~ $ echo -e "line1\nline2\nline3" | showshringbuf -i mylog
root@FB7490:~ $ hexdump /var/.srb_mylog
00000000  f9 13 66 8e 00 00 00 14  00 00 00 3a 00 00 00 4d  |..f........:...M|
00000010  ff ff ff ff 2a 55 75 d4  90 00 07 4c b7 00 00 00  |....*Uu....L....|
00000020  06 6c 69 6e 65 31 00 2a  55 75 d4 90 00 07 4c e8  |.line1.*Uu....L.|
00000030  00 00 00 06 6c 69 6e 65  32 00 2a 55 75 d4 90 00  |....line2.*Uu...|
00000040  07 4d 05 00 00 00 06 6c  69 6e 65 33 00 00 00 00  |.M.....line3....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00008000
root@FB7490:~ $

Wenn man sich jetzt eine beliebige dieser Dateien in der Box unter dem Pfad /var/.srb_* ansieht, stellt man fest, daß die ersten vier Byte immer identisch sind, damit ist die Annahme zu rechtfertigen, das wäre die "Signatur" eines solchen Ringpuffers. Das zweite "Wort" (wir reden hier von 32-Bit-Integerzahlen, die jeweils vier Byte belegen) ist der Offset des ältesten Eintrags im Puffer, hier startet die Ausgabe in aufsteigender Reihenfolge der Einträge. Das dritte Wort ist dann der Offset des letzten geschriebenen Eintrags und das vierte der Zeiger auf den nächsten freien Platz. Spannender wird es jetzt beim fünften Wort in der Datei (wenn das zweite Wort hexadezimal 0x14 ist, besteht der "Kopf" so eines Ringpuffers offenbar aus fünf 32-Bit-Werten und danach werden die Daten gespeichert) ... dort steht offenbar bei anderen Ringpuffer-Dateien der maximale Wert eines Offsets oder auch die Gesamtgröße der Datei minus eins. Bei unserem neuen Puffer steht dort aber ein sehr hoher (vorzeichenlos interpretierter) Wert und somit führen bei dieser Datei auch Schreiboperationen, die über das Dateiende bei 32K hinausgehen würden, zu einem "Segmentation fault". Das können wir aber leicht korrigieren, indem wir ab Verschiebung 16 in der Datei die richtige Größe eintragen. Da man dann auch gleich die Strukturen mit initialisieren kann, ergibt sich in etwa folgendes Skript für das Anlegen eines solchen Ringpuffers:

Code:

#! /bin/sh
#
# create a ring buffer file with the specified name and size
#
name=$1
size=$2
if [ ${#name} -eq 0 -o ${#size} -eq 0 ]; then
	echo "Usage: initshringbuf <logname> <size in KB>" 1>&2
	exit 1
fi
file=/var/.srb_$name
maxoff=$(( size * 1024 - 1 ))
dd if=/dev/zero of=$file bs=1024 count=$size
# signature
echo -ne "\\xF9\\x13\\x66\\x8E" | dd if=/proc/self/fd/0 of=$file bs=4 count=1 conv=notrunc seek=0 2>/dev/null
# first entry
echo -ne "\\x00\\x00\\x00\\x14" | dd if=/proc/self/fd/0 of=$file bs=4 count=1 conv=notrunc seek=1 2>/dev/null
# last entry
echo -ne "\\x00\\x00\\x00\\x14" | dd if=/proc/self/fd/0 of=$file bs=4 count=1 conv=notrunc seek=2 2>/dev/null
# next entry
echo -ne "\\x00\\x00\\x00\\x14" | dd if=/proc/self/fd/0 of=$file bs=4 count=1 conv=notrunc seek=3 2>/dev/null
maxoff=$(printf "%08x" $maxoff)
maxstr=""
while [ ${#maxoff} -gt 0 ]; do
	maxstr="${maxstr}\\\\x${maxoff:0:2}"
	maxoff="${maxoff:2}"
done
# max. offset
eval echo -ne "$maxstr" | dd if=/proc/self/fd/0 of=$file bs=4 count=1 conv=notrunc seek=4 2>/dev/null

Wenn wir dieses Skript jetzt "initshringbuf" nennen (und es ausführbar machen nach dem Speichern), dann ergibt sich folgendes:

Code:

root@FB7490:~ $ initshringbuf mylog 16
root@FB7490:~ $ hexdump /var/.srb_mylog
00000000  f9 13 66 8e 00 00 00 14  00 00 00 14 00 00 00 14  |..f.............|
00000010  00 00 3f ff 00 00 00 00  00 00 00 00 00 00 00 00  |..?.............|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004000

Ok, der Beginn unserer Datei sieht erst einmal richtig aus, mal sehen, was das showshringbuf-Kommando dazu jetzt meint:

Code:

root@FB7490:~ $ showshringbuf mylog
1970-01-01 01:00:00.000 -

Offenbar ein "leerer Ringpuffer", der angezeigte Eintrag am Offset 0x14 ist m.E. nicht zu vermeiden, denn irgendein Offset muß ja im Header stehen. Sowie wir jetzt Daten in den Puffer schreiben, sieht das auch schon wieder besser aus:

Code:

root@FB7490:~ $ echo -e "line1\nline2\nline3" | showshringbuf -i mylog
root@FB7490:~ $ showshringbuf mylog
2015-06-08 20:06:31.348 - line1
2015-06-08 20:06:31.348 - line2
2015-06-08 20:06:31.348 - line3
root@FB7490:~ $ hexdump /var/.srb_mylog
00000000  f9 13 66 8e 00 00 00 14  00 00 00 3a 00 00 00 4d  |..f........:...M|
00000010  00 00 3f ff 2a 55 75 d9  a7 00 05 4f e7 00 00 00  |..?.*Uu....O....|
00000020  06 6c 69 6e 65 31 00 2a  55 75 d9 a7 00 05 50 0e  |.line1.*Uu....P.|
00000030  00 00 00 06 6c 69 6e 65  32 00 2a 55 75 d9 a7 00  |....line2.*Uu...|
00000040  05 50 2e 00 00 00 06 6c  69 6e 65 33 00 00 00 00  |.P.....line3....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004000

Das sieht doch schon sehr gut aus ... bleibt uns noch der Test, ob das mit dem "wrap around" beim Erreichen der max. Größe der Datei auch funktioniert, dazu erstellen wir uns aber eine kleinere Datei, damit die Ausgabe nicht zu lang wird:

Code:

root@FB7490:~ $ initshringbuf mylog 1
root@FB7490:~ $ time sh -c "i=0; while [ \$i -lt 1000 ]; do let i=i+1; echo \"line \$i\" | showshringbuf -i mylog; done"
real    0m 15.90s
user    0m 6.78s
sys     0m 11.01s
root@FB7490:~ $ showshringbuf mylog
2015-06-08 20:19:49.772 - line 957
2015-06-08 20:19:49.787 - line 958
2015-06-08 20:19:49.802 - line 959
2015-06-08 20:19:49.817 - line 960
2015-06-08 20:19:49.833 - line 961
2015-06-08 20:19:49.848 - line 962
2015-06-08 20:19:49.864 - line 963
2015-06-08 20:19:49.879 - line 964
2015-06-08 20:19:49.895 - line 965
2015-06-08 20:19:49.910 - line 966
2015-06-08 20:19:49.925 - line 967
2015-06-08 20:19:49.941 - line 968
2015-06-08 20:19:49.956 - line 969
2015-06-08 20:19:49.972 - line 970
2015-06-08 20:19:49.988 - line 971
2015-06-08 20:19:50.003 - line 972
2015-06-08 20:19:50.019 - line 973
2015-06-08 20:19:50.034 - line 974
2015-06-08 20:19:50.050 - line 975
2015-06-08 20:19:50.065 - line 976
2015-06-08 20:19:50.082 - line 977
2015-06-08 20:19:50.096 - line 978
2015-06-08 20:19:50.111 - line 979
2015-06-08 20:19:50.126 - line 980
2015-06-08 20:19:50.142 - line 981
2015-06-08 20:19:50.157 - line 982
2015-06-08 20:19:50.172 - line 983
2015-06-08 20:19:50.188 - line 984
2015-06-08 20:19:50.204 - line 985
2015-06-08 20:19:50.219 - line 986
2015-06-08 20:19:50.235 - line 987
2015-06-08 20:19:50.251 - line 988
2015-06-08 20:19:50.267 - line 989
2015-06-08 20:19:50.282 - line 990
2015-06-08 20:19:50.297 - line 991
2015-06-08 20:19:50.313 - line 992
2015-06-08 20:19:50.329 - line 993
2015-06-08 20:19:50.345 - line 994
2015-06-08 20:19:50.360 - line 995
2015-06-08 20:19:50.376 - line 996
2015-06-08 20:19:50.392 - line 997
2015-06-08 20:19:50.406 - line 998
2015-06-08 20:19:50.421 - line 999
2015-06-08 20:19:50.436 - line 1000
root@FB7490:~ $ hexdump /var/.srb_mylog
00000000  f9 13 66 8e 00 00 00 ae  00 00 00 82 00 00 00 99  |..f.............|
00000010  00 00 03 ff 2a 55 75 dc  c6 00 05 80 d8 00 00 00  |....*Uu.........|
00000020  09 6c 69 6e 65 20 39 39  35 00 2a 55 75 dc c6 00  |.line 995.*Uu...|
00000030  05 be ee 00 00 00 09 6c  69 6e 65 20 39 39 36 00  |.......line 996.|
00000040  2a 55 75 dc c6 00 05 fb  e5 00 00 00 09 6c 69 6e  |*Uu..........lin|
00000050  65 20 39 39 37 00 2a 55  75 dc c6 00 06 35 91 00  |e 997.*Uu....5..|
00000060  00 00 09 6c 69 6e 65 20  39 39 38 00 2a 55 75 dc  |...line 998.*Uu.|
00000070  c6 00 06 6f fc 00 00 00  09 6c 69 6e 65 20 39 39  |...o.....line 99|
00000080  39 00 2a 55 75 dc c6 00  06 a9 cf 00 00 00 0a 6c  |9.*Uu..........l|
00000090  69 6e 65 20 31 30 30 30  00 00 75 dc c5 00 0b 8a  |ine 1000..u.....|
000000a0  bc 00 00 00 09 6c 69 6e  65 20 39 35 36 00 2a 55  |.....line 956.*U|
000000b0  75 dc c5 00 0b c7 d2 00  00 00 09 6c 69 6e 65 20  |u..........line |
000000c0  39 35 37 00 2a 55 75 dc  c5 00 0c 04 e8 00 00 00  |957.*Uu.........|
000000d0  09 6c 69 6e 65 20 39 35  38 00 2a 55 75 dc c5 00  |.line 958.*Uu...|
000000e0  0c 3e fe 00 00 00 09 6c  69 6e 65 20 39 35 39 00  |.>.....line 959.|
000000f0  2a 55 75 dc c5 00 0c 7a  51 00 00 00 09 6c 69 6e  |*Uu....zQ....lin|
00000100  65 20 39 36 30 00 2a 55  75 dc c5 00 0c b8 3e 00  |e 960.*Uu.....>.|
00000110  00 00 09 6c 69 6e 65 20  39 36 31 00 2a 55 75 dc  |...line 961.*Uu.|
00000120  c5 00 0c f2 e8 00 00 00  09 6c 69 6e 65 20 39 36  |.........line 96|
00000130  32 00 2a 55 75 dc c5 00  0d 2f b3 00 00 00 09 6c  |2.*Uu..../.....l|
00000140  69 6e 65 20 39 36 33 00  2a 55 75 dc c5 00 0d 6b  |ine 963.*Uu....k|
00000150  07 00 00 00 09 6c 69 6e  65 20 39 36 34 00 2a 55  |.....line 964.*U|
00000160  75 dc c5 00 0d a8 9d 00  00 00 09 6c 69 6e 65 20  |u..........line |
00000170  39 36 35 00 2a 55 75 dc  c5 00 0d e5 f4 00 00 00  |965.*Uu.........|
00000180  09 6c 69 6e 65 20 39 36  36 00 2a 55 75 dc c5 00  |.line 966.*Uu...|
00000190  0e 20 f2 00 00 00 09 6c  69 6e 65 20 39 36 37 00  |. .....line 967.|
000001a0  2a 55 75 dc c5 00 0e 5e  c5 00 00 00 09 6c 69 6e  |*Uu....^.....lin|
000001b0  65 20 39 36 38 00 2a 55  75 dc c5 00 0e 99 e3 00  |e 968.*Uu.......|
000001c0  00 00 09 6c 69 6e 65 20  39 36 39 00 2a 55 75 dc  |...line 969.*Uu.|
000001d0  c5 00 0e d8 3c 00 00 00  09 6c 69 6e 65 20 39 37  |....<....line 97|
000001e0  30 00 2a 55 75 dc c5 00  0f 13 fe 00 00 00 09 6c  |0.*Uu..........l|
000001f0  69 6e 65 20 39 37 31 00  2a 55 75 dc c6 00 00 0e  |ine 971.*Uu.....|
00000200  fa 00 00 00 09 6c 69 6e  65 20 39 37 32 00 2a 55  |.....line 972.*U|
00000210  75 dc c6 00 00 4a bf 00  00 00 09 6c 69 6e 65 20  |u....J.....line |
00000220  39 37 33 00 2a 55 75 dc  c6 00 00 87 d6 00 00 00  |973.*Uu.........|
00000230  09 6c 69 6e 65 20 39 37  34 00 2a 55 75 dc c6 00  |.line 974.*Uu...|
00000240  00 c5 53 00 00 00 09 6c  69 6e 65 20 39 37 35 00  |..S....line 975.|
00000250  2a 55 75 dc c6 00 01 00  6e 00 00 00 09 6c 69 6e  |*Uu.....n....lin|
00000260  65 20 39 37 36 00 2a 55  75 dc c6 00 01 40 a1 00  |e 976.*Uu....@..|
00000270  00 00 09 6c 69 6e 65 20  39 37 37 00 2a 55 75 dc  |...line 977.*Uu.|
00000280  c6 00 01 79 df 00 00 00  09 6c 69 6e 65 20 39 37  |...y.....line 97|
00000290  38 00 2a 55 75 dc c6 00  01 b4 2d 00 00 00 09 6c  |8.*Uu.....-....l|
000002a0  69 6e 65 20 39 37 39 00  2a 55 75 dc c6 00 01 ef  |ine 979.*Uu.....|
000002b0  c7 00 00 00 09 6c 69 6e  65 20 39 38 30 00 2a 55  |.....line 980.*U|
000002c0  75 dc c6 00 02 2c f5 00  00 00 09 6c 69 6e 65 20  |u....,.....line |
000002d0  39 38 31 00 2a 55 75 dc  c6 00 02 67 ab 00 00 00  |981.*Uu....g....|
000002e0  09 6c 69 6e 65 20 39 38  32 00 2a 55 75 dc c6 00  |.line 982.*Uu...|
000002f0  02 a2 c9 00 00 00 09 6c  69 6e 65 20 39 38 33 00  |.......line 983.|
00000300  2a 55 75 dc c6 00 02 df  f7 00 00 00 09 6c 69 6e  |*Uu..........lin|
00000310  65 20 39 38 34 00 2a 55  75 dc c6 00 03 1d 5b 00  |e 984.*Uu.....[.|
00000320  00 00 09 6c 69 6e 65 20  39 38 35 00 2a 55 75 dc  |...line 985.*Uu.|
00000330  c6 00 03 59 81 00 00 00  09 6c 69 6e 65 20 39 38  |...Y.....line 98|
00000340  36 00 2a 55 75 dc c6 00  03 98 b4 00 00 00 09 6c  |6.*Uu..........l|
00000350  69 6e 65 20 39 38 37 00  2a 55 75 dc c6 00 03 d5  |ine 987.*Uu.....|
00000360  8d 00 00 00 09 6c 69 6e  65 20 39 38 38 00 2a 55  |.....line 988.*U|
00000370  75 dc c6 00 04 12 fe 00  00 00 09 6c 69 6e 65 20  |u..........line |
00000380  39 38 39 00 2a 55 75 dc  c6 00 04 50 56 00 00 00  |989.*Uu....PV...|
00000390  09 6c 69 6e 65 20 39 39  30 00 2a 55 75 dc c6 00  |.line 990.*Uu...|
000003a0  04 8b b4 00 00 00 09 6c  69 6e 65 20 39 39 31 00  |.......line 991.|
000003b0  2a 55 75 dc c6 00 04 c8  b2 00 00 00 09 6c 69 6e  |*Uu..........lin|
000003c0  65 20 39 39 32 00 2a 55  75 dc c6 00 05 06 a1 00  |e 992.*Uu.......|
000003d0  00 00 09 6c 69 6e 65 20  39 39 33 00 2a 55 75 dc  |...line 993.*Uu.|
000003e0  c6 00 05 44 64 00 00 00  09 6c 69 6e 65 20 39 39  |...Dd....line 99|
000003f0  34 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |4...............|
00000400

Wie man im Hexdump schön sehen kann, landet das "echte Speichern" der 1000. Zeile irgendwo hinter dem Anfang unseres Puffers von 1 KB und unsere Ausgabe mit "showshringbuf" zeigt das trotzdem in ordentlich aufsteigender Folge an, weil nach dem Eintrag für Zeile 994 wieder von vorne in der Datei begonnen wird.

Sofern das alles ohne irgendwelche Fehlermeldungen abgearbeitet wird, funktioniert es offenbar wie erwartet und wir sind jetzt in der Lage, diese Ringpuffer-Speicherung nicht nur mit der Standardgröße von 8 KByte zu verwenden, sondern mit jeder (sinnvollen) Größe, die wir brauchen.

Der Vorteil dieses Vorgehens mit dem Einsatz von "showshringbuf" ist es (für mich), daß man sich nicht selbst darum kümmern muß, wie groß die Protokoll-Datei maximal werden darf (wenn sie im tmpfs liegt und mit steigender Größe den verfügbaren Speicher verringert) und daß man gleichzeitig unnötige Schreiboperationen auf persistente Speicher (z.B. USB-Sticks) vermeiden kann, solange man die protokollierten Daten eigentlich nicht dauerhaft speichern will.

Im Syslog kann man (eine Busybox mit syslogd mal vorausgesetzt) zwar auch in einen Ringpuffer protokollieren, dort gehen aber - nach meiner Ansicht - dann wirklich wichtige Informationen unter bzw. durch die erneute Verwendung des Platzes verloren, wenn man mit entsprechender Frequenz eigene Daten protokollieren will.

Der Ringpuffer-Ansatz von AVM ermöglicht es, diese Daten "nach Typ" getrennt zu protokollieren. Für mich persönlich spielt es auch noch eine Rolle, daß diese Protokollierung aus Skript-Files heraus eben auch mit AVM-Bordmitteln möglich ist, ohne daß man dazu weitere Programme in binärer Form bräuchte.

PS: Sollte das Wissen um diese Möglichkeit schon "Allgemeingut" sein, füge ich eine Quellenangabe hinzu. Andererseits hat mir eine große Internet-Suchmaschine für "showshringbuf" keine zählbaren Ergebnisse geliefert ... daher gehe ich mal davon aus, daß das noch nirgendwo so dokumentiert wurde.

koyaanisqatsi · 10 Jun 2015

Verstehe (nach 3x lesen)

Ich mein, vieles lässt sich ja mit dem syslogd in eine Beschränkte* /var/tmp/messages umleiten.
Dann wird die aber auch schnell voll und unübersichtlich, dann ist grep'en angesagt.

Bei einem Raspberry, wenn es denn nach langer Fehlersuche endlich Schick ist..

Code:

# l /var/log/apache2/
insgesamt 0
lrwxrwxrwx 1 root root 9 Mai 17 10:22 access.log -> /dev/null
lrwxrwxrwx 1 root root 9 Mai 17 10:23 other_vhosts_access.log -> /dev/null

Ich weiss, AVM, aber wäre praktisch(er) wenn in der Fritz!Box in /dev/srb noch was zu finden wäre.

...somit auch: abboniert.

* /var/media/ftp/SanDisk-Cruzer-01/scripts/rc.syslogd

Code:

#!/bin/sh
#Usage: syslogd [OPTIONS]
#
#System logging utility
#
#        -n              Run in foreground
#        -O FILE         Log to FILE (default:/var/log/messages)
#        -l N            Log only messages more urgent than prio N (1-8)
#        -S              Smaller output
[COLOR=#ff0000][B]#        -s SIZE         Max size (KB) before rotation (default:200KB, 0=off)[/B][/COLOR]
#        -b N            N rotated logs to keep (default:1, max=99, [COLOR=#800080][B]0=purge[/B][/COLOR])
#        -R HOST[:PORT]  Log to IP or hostname on PORT (default PORT=514/UDP)
#        -L              Log locally and via network (default is network only if -R)
#        -D              Drop duplicates
#        -C[size_kb]     Log to shared mem buffer (use logread to read it)
#        -f FILE         Use FILE as config (default:/etc/syslog.conf)
#        -K              Log to kernel printk buffer (use dmesg to read it)
local LOGFILE=/tmp/messages
local OPTIONS="-l 8 -S -D [B][COLOR=#ff0000]-s 512[/COLOR][/B] [B][COLOR=#800080]-b 0[/COLOR][/B] -O $LOGFILE"
case $1 in
stop) kill -9 $(cat /var/run/syslogd.pid) ; rm /var/run/syslogd.pid ;;
start) syslogd $OPTIONS ;;
restart) $0 stop ; sleep 1 ; $0 start ;;
*) return 127 ;;
esac
#EOF

PeterPawn · 10 Jun 2015

Wie schon geschrieben ... mit AVM-Bordmitteln!

Und die Busybox einer originalen Firmware enthält (auf den von mir verwendeten Modellen jedenfalls) weder syslogd noch logger oder logread ... das macht es schwierig, bei der Suche auf einer originalen Box Daten zu protokollieren, denn das AVM-Eventlog (eventadd 1 message) eignet sich dafür auch nur bedingt ... dafür ist es allerdings vom GUI aus zugänglich.

Ich protokolliere damit z.B. im 10-Sekunden-Rhythmus den Zustand einer wichtigen VPN-Verbindung (nämlich der zu mir) auf Kundenboxen und steuere parallel dazu mit diesem Überwachungsskript noch eine LED (i.d.R. "Internet-Telefonie") für die optische Anzeige vor Ort, damit die Leute auf den ersten Blick bei einem Fehler sehen können, daß etwas faul ist. Wenn ich dann nachsehen (lassen) will, seit wann (ggf. auch warum) das so ist, reicht ein 64 KB-Ringpuffer dafür in aller Regel vollkommen aus (es gibt eine zusätzliche GUI-Seite für die Anzeige dieses Puffers auf den Boxen) und die Leute werden nicht durch Nachrichten aus verschiedenen Quellen irritiert (was beim - ohnehin nicht vorhandenen - syslogd der Fall wäre), wenn sie mir das telefonisch durchgeben sollen (weil ich dann i.d.R. keinen Zugriff mehr habe

).

koyaanisqatsi · 11 Jun 2015

Moins

Das mit dem erweiterten Pfad und "erweiterten" busybox syslogd hätte ich angeben sollen, mein Fehler.

Momentan ist es bei meiner Firmware (7360SL 6.20) so,
dass der telnetd zwar deaktiviert werden kann,
danach aber nicht mehr aktiviert.
Den krieg ich aber komischerweise durch einen Import einer Export wo der aktiviert war wieder an.
:gruebel: (mal so am Rande)

LED
OK, dass versteh ich gut.
Mach ich auch gerne.
Mein Favorit: filesystem_mount_failure (hatten wir ja schon?)

Also, wenn ich mal so ein bischen in Richtung Pseudofirmware schiele.

1. Könnten so mit Bordmittel nachinstallierte Programme in Ringpuffer loggen?
2. Mindestens den telnetd* wieder starten oder ersetzen (umbenannte busybox?

**)
3. Sonstige "nützliche" Dinge tun

* AVM scheint den abschaffen zu wollen.
Vielleicht wieder so aktivieren, wie die Import/Export (binfile?), aber echt keine Ahnung
Und: Ja, ich bevorzuge dropbear gegenüber telnetd.
Bloss telnetd ist (noch) in F!B und in einer Eigenen busybox.

** Wer weiss schon das /var/tmp/telnetd in Wirklichkeit eine umbenannte busybox ist?***

*** Humor

Falls es dich, vergleichsweise, interessiert...
auf 7360SL 6.20

Code:

/var/tmp # /var/media/ftp/SanDisk-Cruzer-01/scripts/initshringbuf.sh koy 1
1+0 records in
1+0 records out
1024 bytes (1.0KB) copied, 0.000370 seconds, 2.6MB/s
/var/tmp # time sh -c "i=0; while [ \$i -lt 1000 ]; do let i=i+1; echo \"line \$i\" | showshringbuf -i koy; done"
real    0m 18.02s
user    0m 7.35s
sys     0m 10.83s
/var/tmp # showshringbuf koy|head
2015-06-11 02:35:49.078 - line 957
2015-06-11 02:35:49.092 - line 958
2015-06-11 02:35:49.106 - line 959
2015-06-11 02:35:49.120 - line 960
2015-06-11 02:35:49.134 - line 961
2015-06-11 02:35:49.147 - line 962
2015-06-11 02:35:49.162 - line 963
2015-06-11 02:35:49.176 - line 964
2015-06-11 02:35:49.190 - line 965
2015-06-11 02:35:49.204 - line 966
/var/tmp # showshringbuf koy|tail
2015-06-11 02:35:49.636 - line 991
2015-06-11 02:35:49.659 - line 992
2015-06-11 02:35:49.675 - line 993
2015-06-11 02:35:49.695 - line 994
2015-06-11 02:35:49.728 - line 995
2015-06-11 02:35:49.750 - line 996
2015-06-11 02:35:49.772 - line 997
2015-06-11 02:35:49.794 - line 998
2015-06-11 02:35:49.822 - line 999
2015-06-11 02:35:49.848 - line 1000

...fast 3 Sekunden langsamer.

EDIT: /var/.srb_koy
So, wie es aussieht, lässt sich die Grösse im Betrieb verändern.
Natülich zu einem "sicheren" Zeitpunkt.
Putzt die dabei sauber, weil Neuerstellt.
Das hat schon was.

PeterPawn · 2 Feb 2021

Die Beschreibung des Formats in #1 entspricht nicht mehr in allen Details dem aktuellen Stand in der AVM-Firmware. Einen aktualisierten Vorschlag für ein Skript zum Anlegen einer eigenen Datei (iirc ist bei 64KB aber ohnehin Schluß, auch wenn die Offsets 32-Bit-Werte sind - aber das könnte man auch noch einmal neu überprüfen, ich bin nicht sicher, daß ich die Beschränkung auf 64 KB nach der Änderung des Formats erneut getestet hatte, auch wenn sich bei AVM keine Dateien dieser Art finden, die größer wären) findet man im "modfs"-Projekt: https://github.com/PeterPawn/modfs/blob/master/modfs#L2754 - das prüft die vorhandene Version von "showshringbuf" und legt die Datei mit dem dazu passenden Format an.

Nur falls jemand heutzutage mal wieder über diesen Thread stolpern sollte ...

Languages

Suche

Languages

Suche

[Info] Volatile Protokollierung mit AVM-Bordmitteln

PeterPawn

IPPF-Urgestein

koyaanisqatsi

IPPF-Urgestein

PeterPawn

IPPF-Urgestein

koyaanisqatsi

IPPF-Urgestein

PeterPawn

IPPF-Urgestein

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums