PANIC: fatal region error detected; run recovery

Ok, vorweg, es geht nicht um GeoIPs, Zeitzonen oder andere Sachen die mit geografischen Regionen zutun hat ūüôā

PANIC: fatal region error detected; run recovery

Das ist eine Meldung der BerkeleyDB, einer filebasierten einfachen Datenbank, die Programme gern benutzen, wenn Sie keinen richtigen Datenbankbackend brauchen/wollen. Eins der Programme ist der Webalizer, ein Analysetool , das jedem statistiks√ľchtigen¬† Apachenutzer¬† ein Begriff sein d√ľrfte.

Es kann vorkommen, daß diese Datenbank beschädigt wird. Die Anwendung gibt dann die obige Fehlermeldung aus, oder auch nicht, weil nach >dev/null umgeleitet.

Woran merkt man das also, wenn dieser Fehler auftritt ?

Zun√§chst mal, macht Webalizer nichts mehr, er kommt nicht mehr voran, weil … keine Ahnung wie man so fehlerintolerant programmieren kann, ich wei√ü es nicht. Also das Teil bleibt einfach stehen. Das sieht dann so aus:

           |-sshd(878)-+-sshd(3593)---sshd(3619)---bash(3631)---webalizer(13066)---java(13074)-+-webalizer(16621)-+-webalizer(16623+
           |           |                                                                       |                  |-webalizer(16624+
           |           |                                                                       |                  |-webalizer(16625+
           |           |                                                                       |                  |-webalizer(16626+
           |           |                                                                       |                  |-webalizer(16627+
           |           |                                                                       |                  |-webalizer(16628+
           |           |                                                                       |                  |-webalizer(16629+
           |           |                                                                       |                  |-webalizer(16630+
           |           |                                                                       |                  |-webalizer(16631+
           |           |                                                                       |                  `-webalizer(16632+

im TOP und IOTOP sieht man Webalizer kann auch nicht mehr auftauchen, weil die Prozesse in einem QuasiSleep sind.

Wenn man jetzt auf den Hauptprozess (oben die PID 16621 ) ein strace anwendet mit „strace -s 1024 +f +p 16621“ bekommt man das zu sehen:

strace: Process 16621 attached
write(2, "BDB0060 PANIC: fatal region error detected; run recovery", 56

und nichts passiert mehr. In dem Fall kann man strace einfach abbrechen und getrost die dns_cache.db löschen:

rm -f /var/lib/webalizer/dns_cache.db

Dann bricht man den Webalizer Hauptprozess mit kill ab, und startet das Ganze von vorn. Fertig.

Abweichungen von Webstatistiken und WordPress

Ich glaube, die Jetpack-Wordpress-Statistik l√ľgt uns Blogger an.

Dummerweise gibt es keine Infos auf den Jetpackseiten, was genau die da tracken, nur was sie nicht tracken, nämlich einen selbst.

Nun habe ich noch die guten alten Webalizerauswertungen durchgesehen und konnte f√ľr einzelne Beitr√§ge teilweise den zehnfachen Zugriff feststellen.

Beispiel:

Der Beitrag „QMMP & MP3 & Fedora 24“ wurde laut Jetpackstats gestern 18x aufgerufen. Es gibt aber alleine gestern in den Webstats 352x Aufr√ľfe der Landingpageurl f√ľr diesen Artikel.

Bei genauerer Analyse der Aufrufer, stammen viele von Google. Lassen wir die weg, sind es noch 212 Anfragen.
Werfen wir alle doppelten IPs raus, bleiben noch 112 unique IPs √ľbrig.

Das sind 500% mehr Zugriffe, als Jetpack dem Blog zugestehen will. Und das war nur eine von zwanzig Landingpages an dem Tag.

Warum zählt Jetpack das nicht, weiß das wer ?

Wie kommt man an diese Zahlen auf die schnelle ran ?

Zunächst mal braucht man einen Webserver z.b. einen Apache httpd und den passenden VirtualHost Eintrag um die Logfiles zu schreiben:

    ServerName bloggt-in-braunschweig.de
    ServerAlias *.bloggt-in-braunschweig.de
    ErrorLog logs/error_log
    CustomLog domlogs/bloggt-in-braunschweig.de combined

Weil son Tag erst richtig ausgewertet werden kann, wenn er vorbei ist, macht man das einen Tag später, weswegen auf einem normalen Webserver die Logfiles schon weggepackt wurden, damit sie wenig Platz benötigen. Da das am Tag +1 zum eigentlich Datum geschieht, sieht die Zeile auf meinem Fedora Server so aus :

zgrep „13/Jul/2016“¬† bloggt-in-braunschweig.de.20160714.gz | grep¬† „GET /2016/07/13/qmmp-mp3-fedora-24“ | grep -v „google“ | awk ‚{print $1;}‘ | sort -u | wc –lines

Damit Ihr Euch das vorstellen könnt, hier eine Beispiellogzeile:

5.35.243.228 – – [13/Jul/2016:20:40:35 +0200] „GET /2016/07/13/qmmp-mp3-fedora-24/ HTTP/1.1″ 200 40382 „-“ „Friendica ‚Lily of the valley‘ 3.4.3-2-1191; https://friend.sraega.org“

Die interessanten Teile, habe ich hervorgehoben.

Der Befehl ‚zgrep „13/Jul/2016“ ‚ filtert uns nur Eintr√§ge von dem Tag aus dem mit GZIP gepackten Logfile.
Mit ‚grep¬† „GET /2016/07/13/qmmp-mp3-fedora-24“‚ filtern wir auf die Landingpage, d.h. die Aufrufe des Artikels, die geschehen sind, als er Startbeitrag auf der Startseite war und diese aufgerufen wurde, werden so nicht mitgez√§hlt.
Das „grep -v google“ wirft den Googleboot raus, ziemlich penetranter kleiner Kerl √ľbrigens, der kommt schon fast im 5 Minuten Takt an der Landingpage vorbei um zu schauen, ob die sich ge√§ndert hat.
AWK sollte man als Admin kennen, hier wird es benutzt um nur die IP, die als erstes in der Logzeile steht, auszufiltern.
sort -u “ kickt die doppelten Eintr√§ge der IP raus.
wc –lines“ z√§hlt dann die √ľbrig gebliebenen Zeilen, also das Ergebnis.

Und das Ergebnis war 112x .

Jetzt fragt man sich, was WordPress da eigentlich statistisch erfa√üt und ohne in den Code schauen zu wollen, w√ľrde ich sagen: kompletten Schrott ūüôĀ

Bestenfalls kann man an dem Ergebnis ablesen, wie Trends einzelnen Blogbeiträge so liegen, aber das wars schon.

Am Beispiel vom SuperTuxKart Beitrag von heute: 22x laut WordPress, 134x laut Apachelogfile (-google und doppelten)  (bis zu diesem Artikel) also auch wieder Faktor 6 ( 500% mehr ) Abweichung.

D.h. ab sofort geht mir die Statistik am …… vorbei ūüėÄ

Update: ein Plugin soll das Problem l√∂sen, indem es den Job √ľbernimmt. Ich hab es mal aktiviert. Also nicht wundern wenn es die n√§chsten Tage noch wenig anzeigt.