[Gelöst] syslogd: Überlaufen der Logdatei

hermann72pb · 18 Mai 2007

In einem anderen Thread hatte ich bereits syslogd als Übeltäter für das Aufhängen von 7050 festgestellt. Meine weitere Experimente mit Einstellungen in syslogd zeigten eine Reihe weiterer möglicher Fehlerquellen, die bei bestimmten Einstellungen zum Überlaufen der Logdatei führen können.
1. Meine erste Einstellung war die Defaulteinstellung: In Ringpuffer loggen. Die Dateigröße hatte ich hier leer gelassen. Vermutlich war dies das Problem. Folge: Box nach einigen Stunden "eingeschlafen". Dazu die Frage: Was ist eigentlich Ringpuffer? Wo liegt diese Datei physikalisch? Ist es überhaupt sinnvoll dahin zu loggen?
2. Nachdem ich mit Ringpuffer Probleme hatte, habe ich zunächst syslogd komplett deaktiviert. Damit lief meine Box stabil. Also, hat es definitiv damit zu tun.
3. Danach hatte ich die Logdatei manuell nach /var/tmp/loglog geleitet. Bei einer Größe von 5kB und einer Anzahl der Logdateien von 2 läuft alles wunderbar. Zusätzlich zu loglog existierten noch zwei Dateien loglog.0 und loglog.1.
4. Stelle ich jedoch die Anzahl der Dateien auf 1, so funktioniert das Rotieren nicht mehr. Mache ich etwas falsch?

MfG

kriegaex · 19 Mai 2007

1. Ein Ringpuffer liegt im RAM und hat seinen Namen daher, daß, wenn er hinten voll läuft, alte Nachrichten raus fliegen und neue hinten angehängt werden. Es ist so eine Art Queue begrenzter Länge. Der Kernel hat einen Ringpuffer, der Syslogd optional ebenfalls.

2. Wenn der Ringpuffer Probleme macht, dann muß es schon verdammt eng in Deinem Speicher zugehen. Standardmäßig ist er für den Syslogd 16 KB groß, das ist nicht viel. Evtl. könnte es auch am Syslogd selbst liegen, das weiß ich nicht.

3./4. Vielleicht denkt Syslogd, ein einziges Backup lasse sich schlecht rotieren, obwohl der sinnvolle Fallback in dem Fall wäre, einfach das eine Backup zu überschreiben. Evtl. wird ist da ein kleiner Busybox-Bug im Code fürs Rotieren, habe nicht nachgeschaut.

hermann72pb · 19 Mai 2007

Dann mein Rezept für syslogd bis die Probleme geklärt sind:
1. Ringpuffer möglichst nicht verwenden
2. Stattdessen in eine Datei im RAM loggen, z.B. /var/tmp/loglog
3. Die Dateigröße nicht allzugroß einstellen, z.B. 5kB oder 10kB
4. Anzahl zu rotierenden Dateien auf mindestens 2 einstellen

Dann sollte es mit dem syslog klappen.

Wer natürlich einen Logserver hat, kann die Variante nehmen. Und Logdateien ab und zu anzuschauen macht wirklich Sinn. Heute über Nacht z.B. hat jemand mehrmals versucht mein dropbear mehrmals zu knaken. Aber das ist hier definitiv OT.

MfG

kriegaex · 19 Mai 2007

Wie gesagt, der Ringpuffer ist auch im RAM und sollte auch nicht überlaufen, da es sich ja um einen Speicherbereich fester Größe handelt. Aber wenn Du mit den rotierenden Logs zurecht kommst, ist das super - tu das.

hermann72pb · 19 Mai 2007

rc.syslogd

Ich hatte einen Blick in rc.syslogd gemacht:

Code:

case "$SYSLOGD_LOGGING" in
circular_buffer)
	if [ ! -z "$SYSLOGD_BUFFER_MAXSIZE" -a "$SYSLOGD_BUFFER_MAXSIZE" -ne "16" ]; then
		SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -C$SYSLOGD_BUFFER_MAXSIZE"
	else
		SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -C"
	fi
;;
log_to_file)
	if [ ! -z "$SYSLOGD_ALTERNATIVE_LOGFILE" ]; then
		SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -O $SYSLOGD_ALTERNATIVE_LOGFILE "
	fi
	if [ "$SYSLOGD_MAXFILES" -gt "1" ]; then
		SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -b $SYSLOGD_MAXFILES -s $SYSLOGD_MAXSIZE "
	fi
;;
esac

1. Den ersten Abschnitt mit -z und -a verstehe ich als Nicht-Informatiker nicht. Kann mir bitte jemand auf die Sprünge helfen und sagen, was passiert, wenn $SYSLOGD_BUFFER_MAXSIZE leer ist (das war und ist bei mir definitiv der Fall!)? Gibt es da eine Idiotensicherung gegen leere Variable oder nicht?
2. Im zweiten Abschnitt sehen wir "-gt" (also größer, nicht größer-gleich), was meine Befürchtung von oben erklärt. Die Frage ist, ob es bewußt gemacht wurde, weil z.B. es sonst nicht geht, oder ob es ein Fehler nur hier im Skript ist.

Man könnte durch "Expertenoptionen" die Variante mit einer Logdatei jetzt schon ausprobieren. Wenn ich dazu komme, dann mache ich es, sonst werde ich nicht böse, wenn es jemand ausprobiert und hier darüber berichtet. Expertenoptionen lauten dann (als Beispiel für 1. Datei /var/tmp/loglog von 5kB Größe):

Code:

-L -O /var/tmp/loglog -b 1 -s 5

Edit: Ich war doch zu neugierig. Also die oben genannte Variante mit einer Datei funktioniert. In diesem Falle wird eine zusätzliche Datei loglog.0 neben loglog erzeugt.
Mein Vorschlag wäre:
Den zweiten Abschnitt so zu ändern, dass zunächst "-ge" anstatt "-gt" dort steht, sonst (jedem IF sein ELSE: Idiotensicherung) die Optionen "-b 1 -s 16" (als Beispiel) hinfügen. Es wäre für die Box viel sicherer, als RAM-Überlauf bei falschen Einstellungen zu riskieren.
Ähnlich würde ich auch mit Ringpuffer vorgehen. Ich konnte leider nicht feststellen, ob es bei Defaulteinstellung "-C" (ohne Parameter) wirklich 16kB als Puffer genommen werden.

Könnte es jemand bitte einpflegen?

MfG

olistudent · 20 Mai 2007

Hi.
In der default-config für die bb steht "CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16". Daher gehe ich davon aus, dass die 16 KB stimmen.

MfG Oliver

edit: Die Änderungen würden dann so aussehen:

Code:

@@ -33,7 +33,7 @@
 
        case "$SYSLOGD_LOGGING" in
        circular_buffer) 
-            if [ ! -z "$SYSLOGD_BUFFER_MAXSIZE" -a "$SYSLOGD_BUFFER_MAXSIZE" -ne "16" ]; then
+            if [ ! -z "$SYSLOGD_BUFFER_MAXSIZE" ]; then
                SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -C$SYSLOGD_BUFFER_MAXSIZE"
            else
                SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -C"
@@ -44,7 +44,7 @@
            if [ ! -z "$SYSLOGD_ALTERNATIVE_LOGFILE" ]; then
                SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -O $SYSLOGD_ALTERNATIVE_LOGFILE "
            fi
-            if [ "$SYSLOGD_MAXFILES" -gt "1" ]; then
+            if [ "$SYSLOGD_MAXFILES" -ge "1" ]; then
                SYSLOGD_OPTIONS="$SYSLOGD_OPTIONS -b $SYSLOGD_MAXFILES -s $SYSLOGD_MAXSIZE "
            fi
        ;;
@@ -59,6 +59,11 @@
        fi
    fi
 
+    #fallback
+    if [ -z "$SYSLOGD_OPTIONS" ] && [ -z "$SYSLOGD_EXPERT_OPTIONS" ]; then
+        SYSLOGD_OPTIONS="-b 1 -s 16"
+    fi
+    
    $DAEMON $SYSLOGD_OPTIONS $SYSLOGD_EXPERT_OPTIONS > /dev/null 2>&1
    exitval1=$?

kriegaex · 20 Mai 2007

Genau dorther hatte ich die Information auch.

Was -b $SYSLOGD_MAXFILES betrifft, ist es tatsächlich so, daß -b 1 erlaubt sein sollte (es bedeutet etwas anderes als -b 0), weswegen das Größer-Gleich in Ordnung geht. Ich checke das ein und betrachte es als durch Hermann getestet.

Referenz zum Parameter:

Code:

$ syslogd --help
BusyBox v1.4.2 (2007-05-15 15:41:43 CEST) multi-call binary

Usage: syslogd [OPTION]...

System logging utility.
Note that this version of syslogd ignores /etc/syslog.conf.

Options:
    -m MIN          Minutes between MARK lines (default=20, 0=off)
    -n              Run as foreground process
    -O FILE         Use an alternate log file (default=/var/log/messages)
    -l n            Sets the local log level of messages to n
    -S              Make logging output smaller
    -s SIZE         Max size (KB) before rotate (default=200KB, 0=off)
    [B]-b NUM        Number of rotated logs to keep (default=1, max=99, 0=purge)[/B]
    -R HOST[:PORT]  Log to IP or hostname on PORT (default PORT=514/UDP)
    -L              Log locally and via network logging (default is network only)
    -C[size(KiB)]   Log to a shared mem buffer (read the buffer using logread)

hermann72pb · 20 Mai 2007

ok. Dann markiere ich das Thema als gelöst

MfG

ao · 21 Mai 2007

hermann72pb schrieb:
Und Logdateien ab und zu anzuschauen macht wirklich Sinn. Heute über Nacht z.B. hat jemand mehrmals versucht mein dropbear mehrmals zu knaken.

Wie heisst nochmal die Methode, bei solchen Angriffen die IPs zu loggen und nach n-maligen Angriffen die IP (für eine bestimmte Zeit x) komplett zu blockieren?
Ich würde dann gerne nach der Methode suchen und checken, ob man das für die 7050 oder 7170 implementieren kann.
Vielen Dank!

kriegaex · 21 Mai 2007

Das ist ein wenig OT, aber sei's drum: Es gibt keinen dezidierten Befehl, der mir bekannt wäre. So etwas hinterlegt man am besten als Regel oder Einstellung in einer Firewall. Meines Wissens bietet die AVM-Firewall solche Möglichkeiten nicht, man könnte da höchstens per Shell-Skript die Logs auswerten und dann von Hand die Einstellungen der Firewall bzw. des betroffenen Dienstes (z.B. sshd, also dropbear) manipulieren. Irgendwann müßte man die Sperre auch wieder automatisch aufheben. Das wäre recht aufwendig.

Alternative 1: Iptables. Ich nehme an, damit geht sowas, aber ich verwende das Paket nicht.

Alternative 2: Betroffene Ports überhaupt nur dann kurzzeitig aufmachen, wenn eine bestimmte Anklopf-Sequenz vorher den Anklopfenden grob authentifiziert. Dann laufen solche Angriffe von vorne herein ins Leere. Das Paket Knockd bietet die entsprechende Funktionalität, aber auch das benutze ich bisher nicht. Du findest im IPPF sicher Infos dazu, evtl. auch im Wiki.

doppelfritz · 21 Mai 2007

@ao
Wenn du die Logdatei irgendwo hinlegst, wo du sie mit Linux Tools auswerten kannst und ip-tables und cron(ist ja sowieso im Mod) auf der Box hast ist das bestimmt machbar.
Von einer fertigen Lösung für sowas habe ich noch nichts gelesen.

hermann72pb · 29 Mai 2007

Nochmal zum Ringpuffer

Da wir an der anderer Stelle mit kriegaex wieder eine Diskussion über Ringpuffer hatten, erwecke ich das Thema nochmal zum Leben.

Meine Fragen:
1. Hat jemand schon gemerkt, dass die Box mit einem eingeschalteten syslogd und Default-Einstellungen (loggen in Ringpuffer, Ringpuffer-Größe leer) nach einer gewissen Zeit hängen bleibt (LEDs leuchten, Box reagiert nicht)?
2. Wurde dieses Verhalten auch bei anderen Boxen als 7050 gesichtet?

Bitte melden, sonst entsteht der Eindruck, dass ich der einzige bin, der das Problem hat.

3. Wie kann man Ringpuffer-Größe mit Bordmittel beobachten? Ich würde es gerne tun, befürchte aber, dass es eher ein Speicherbereich ist und keine Datei, sodass es schwierig wird.

MfG

kriegaex · 29 Mai 2007

Olistudent hat auf seiner Fon WLAN auch mal den Syslogd mit Ringpuffer laufen lassen und keinen erhöhten Speicherverbrauch, auch keine sonstigen Probleme festgestellt. Ich zitiere ihn (gekürzt):

Code:

$ ps | grep syslogd
  826 root        380 S   syslogd -L -C

$ uptime
 13:06:35 up 1 day, 15 min, load average: 0.13, 0.04, 0.01

$ free
              total         used         free       shared      buffers
Total:        30364        29092         1272
$ killall syslogd
$ free
              total         used         free       shared      buffers
Total:        30364        28972         1392

user098 · 30 Mai 2007

Ich weiß es noch nicht die Ursache für das Aufhängen ~~heute~~ gestern, aber es könnte an dem Ringpuffer von syslogd liegen. Downloader benutze ich nicht, die Pakete, die im DSMod sind: Callmonitor, dnsmasq und syslogd. Ringpuffer war auf 16k eingestellt. Jetzt habe ich erstmal syslogd gestoppt, um zu schauen, ob FBF sich nochmal aufhängt oder nicht

hermann72pb · 30 Mai 2007

@user098: Das heißt, das Feld für die Ringpuffer Größe im WebIF war bei dir nicht leer, wie es default der Fall ist, sondern du hast es explizit auf 16kB gesetzt. Und danach kam es zum Aufhängen. Gut zu wissen. Wenn man jedoch rc.syslogd anschaut, stellt man fest, dass Puffergröße gleich 16kB genau so abgefangen wird wie das leere Feld und syslogd wird mit den gleichen Parametern gestartet:

Code:

syslogd -L -C

also ohne Größe hinter "-C".
Deine Konfiguration kennen wir schon, du hast sie im anderen Thread gepostet. Ich habe sie sogar bereits als erfolgreiches Beispiel zitiert.
Wie sieht es bei dir eigentlich mit LCR aus? Benutzt du das Paket oder hast du es irgendwann mal benutzt? Es gab ähnliche Aufhänge-Probleme, die auf LCR zurückzuführen waren. Im Unterschied zu syslog-Problemen treten LCR-Probleme in definierten Abständen auf. Wenn es nicht der Fall ist, probiere bitte Folgendes:

1. Sicher zu stellen, dass die Box ohne syslogd nicht aufhängt (36-48 Stunden sind genug)
2. Im syslogd die Option "Kernel loggen" aktivieren. Dann geht es mit "zumühlen" schneller. War es bei dir eigentlich vorher aktiviert?
3. Die Puffergröße des Ringpuffers auf z.B. 15kB einstellen. Dann wird syslogd auch definiert mit dieser Größe gestartet.
4. Auf der Box free ab und zu ausführen.
5. Deine Erkenntnisse hier posten.

@kriegaex:Hier ist meine free:

Code:

/var/mod/root $ free
              total         used         free       shared      buffers
  Mem:        30352        26248         4104            0          872
 Swap:            0            0            0
Total:        30352        26248         4104

Wohl gemerkt auf einer 7050 mit den ganzen aufgeladenen Paketen. Oliver benutzt keinen Downloader und hat nicht OpenVPN, dropbear und mc noch nebenbei im RAM sitzen.
Man muss übrigens nach dem start oder stop des Dienstes vor dem nächsten free etwas abwarten, bis sich das Ganze beruhigt hat. Bei mir sah es dynamisch so aus:
4144 -> [start im gui] -> 3928 -> 3972 -> 4020 (nach etwa 10 sek.)
Warum ich plötzlich im 4MB-Bereich lande, ist für mich auch ein Rätsel. Früher hatte ich auch nur 1-2 MB frei. Vielleicht hat sich etwas in 33-Firmware geändert?
Ich lasse jetzt auch syslogd mit ringpuffer laufen, bis die Box steht.

MfG

user098 · 30 Mai 2007

Zu LCR: Meine FB weiß noch gar nicht was LCR ist. Noch nie nötig gewesen.
Zu 1. z. Zt. läuft FB ohne syslogd, morgen schalte ich es ein.
Zu 2. Ja, Kernel loggen war aktiviert
Zu 3-5. ok, werde beobachten

So nebenbei: hat FB keinen Watchdog? Wenn ja, warum startet sich die Box nicht neu? Das schlimme ist ja, dass alle LEDs leutchen, als würde alles funktionieren, nur wenn mn Telefonhörer abhebt, bekommt man eine Stille

kriegaex · 30 Mai 2007

Die FB hat einen Watchdog. Er wird über ein Device gesteuert, wie man z.B. in /etc/init.d/rc.S sehen kann:

Code:

echo init-start 120 >/dev/watchdog
# ...
echo init-done >/dev/watchdog

hermann72pb · 30 Mai 2007

@user098: Es wurde hier im IPPF schon darüber spekuliert, was da passieren kann. Eine Idee war: Im RAM wird eng, alle Programme, die RAM-Anfrage senden (dass sie RAM-Resourcen brauchen), bekommen eine Antwort: "warte mal". Dadurch befinden sich irgendwann mal fast alle Programme auf der Box in diesem Dauerwartezustand.

MfG

user098 · 30 Mai 2007

Also die FB lief ca. 50 Stunden einwandfrei ohne syslogd. Dann habe ich syslogd gestartet mit Ringpuffer. Und nach ca. 3 Stunden war es so weit, die Box hat sich aufgehängt. Ich beobachtete ganze Zeit die Speicherbelegung, es waren durchgehend ca. 1400 - 1600 Kb frei. Ringpuffergröße war auf 21Kb eingestellt. Jetzt läuft syslogd mit Logdateien, mal schauen was daraus wird.

hermann72pb · 31 Mai 2007

aber Logdateien hast du mindestens 2 eingestellt?
Ich habe seit gestern Ringpuffer mit Default-Einstellungen am Laufen. Bis jetzt noch keine Probleme festgestellt, obwohl Kernelloggen aktiviert ist und OpenVPN ständig aktiv läuft (früher war es nicht möglich). Ich mache deswegen so eine still-leise und vorsichtige Vermutung, dass der besagte Effekt nur mit frisch installierten Boxen vorkommt. Aber lass uns noch weiter testen.
Die andere Sache, die mir unklar ist: Warum zeigt meine Box fast dauernd 3,7-4 MB RAM als frei (free), obwohl dieser Wert normalerweise (früher bei mir und sonst bei anderen hier im Forum) zwischen 1 und 2 MB liegt?

MfG

[Gelöst] syslogd: Überlaufen der Logdatei

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Anhänge

Aktives Mitglied

IPPF-Promi

IPPF-Urgestein

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

Aktives Mitglied

Neuer User

IPPF-Promi

Aktives Mitglied

Mitglied

IPPF-Promi

Mitglied

Aktives Mitglied

IPPF-Promi

Mitglied

IPPF-Promi

Statistik des Forums