Marco Gabriel

Die Webkrauts zeigen, wie man seinen Wysiwyg Editor in Modx, Wordpress oder anderen Umgebungen erweitert und dem eigenen Bedarf anpasst. Mir kam das heute sehr gelegen.

Es gibt für PHP ja so einige Möglichkeiten, Logs zu erzeugen. Apache Log4PHP dürfte die bekannteste sein, aber ich suchte etwas ganz einfaches und habe KLogger gefunden.

Einfaches Beispiel:

$log = new KLogger('/var/log/'); # Specify the log directory
$log->logInfo('Returned a million search results'); //Prints to the log file
$log->logFatal('Oh dear.'); //Prints to the log file
$log->logInfo('Here is an object', $obj); //Prints to the log file with a dump of the object

Ideal für meinen Einsatzzweck und in wenigen Minuten implementiert.

Ab und an dauert ein rsync Job länger als geplant. Wenn man sicherstellen möchte, dass rsync in einem Cronjob nur ausgeführt wird, falls es nicht schon läuft, kann man folgendes Konstrukt verwenden:

pgrep -c rsync || rsync [options] quelle ziel

Ich hatte das vor einiger Zeit bei Serverfault schon mal als Antwort eingestellt, aber eigentlich ist es in meinem Blog auch gut aufgehoben. 

Eben mal ein Update von der 4.1 auf die aktuelle Virtualbox 4.2 durchgeführt. Für daheim ist das ganz prima und tut genau das was es soll. Es ist an sich, obwohl es zwischenzeitlich im Rahmen der SUN Übernahme von Oracle geschluckt wurde, ein hervorragendes Werkzeug für die Virtualisierung auf dem Desktop. Man kann damit relativ schnell Testszenarien bauen, anpassen und wieder verwerfen.

Für die Server Virtualisierung würde ich es jedoch nicht verwenden. Da bleibe ich lieber bei Proxmox VE.

Ein bestimmter Server wurde in letzter Zeit immer unzuverlässiger und stürzte öfter mal ab, ohne dass wir eine genaue Ursache ausmachen konnten. Gestern habe ich mich dem Server noch mal angenommen und ein bisschen Ursachenforschung betrieben. Ein einfaches ls -la /var/log dauerte schon ewig. Ich spekulierte schon über einen Festplattenschaden bis ich dann irgendwann tatsächlich eine endlose Dateiliste zu sehen bekam.

Ein ls -la | wc -l brachte hervor, dass in diesem Ordner mehr als 1,3 Millionen Files lagen. Kein Wunder, dass  der Server dabei ab und an mal Schwierigkeiten hat. Die Ursache war, dass sich auf Debian/Ubuntu Systemen der sysklogd und logrotate gegenseitig in die Quere kommen. Aber dazu vielleicht ein anderes Mal mehr. Nun musste ich erst mal die ganzen überflüssigen Dateien löschen.

Das ist etwas leichter gesagt als getan, denn ein rm /var/log/mail.0.* brachte schon einen Fehler, dass die Liste der Dateien zu gross sei.

Lösung 1:

find /var/log -name "mail.0.*" -exec rm '{}' \;

find bearbeitet jede Datei einzeln, startet dann rm um die einzelne Datei zu löschen. Das funktionierte grundsätzlich, löschte allerdings nur ca. 150 Files pro Sekunde. Somit hätte der gesamte Vorgang 144 Stunden oder 6 ganze Tage gedauert. Ich brauchte eine andere Lösung.

Lösung 2:

find /var/log -name "mail.0.*" -delete -print

Damit übergibt find die Dateien nicht mehr an rm, sondern löscht sie gleich selbst. Damit erreichte ich ca. 2.000 Files pro Sekunde. Der gesamte Vorgang verkürzte sich somit auf ca. 10 Minuten. Das -print ist übrigens nur notwendig, wenn man sehen möchte, welche Dateien find löscht. Ohne Ausgabe dürfte es noch etwas schneller gehen. Na Also, geht doch. 

EDIT: Da der Artikel in einer früheren Version unfertig gespeichert wurde, habe ich die fehlenden Lösungen noch ergänzt . 

EDIT 2: "-name" ergänzt. Falscher Fehler in meiner Erinnerung.