Ich habe gerade ein nettes Microblogging-Plugin für Pidgin ("microblog-purple") gefunden.
Jetzt versuche ich mal die freie und offene Alternative zu Twitter: identi.ca. Mal schauen ob ich beim "Microbloggen" fleißiger bin als beim normalen Blog ;)
Für die es interessieren sollte: hier ist mein Microblog zu finden.
Samstag, 20. März 2010
Montag, 27. Juli 2009
"memtest86+" - meine Rettung...
Diese Woche hatte ich zahlreiche Schreckminuten - eine Kernelpanic nach der nächsten... obwohl genau diese Konfiguration eine Uptime von >450 Tagen hatte und immer problemlos funktioniert hat.
Ich habe den Linux-Kernel des Hosts auf meinem VServer-System getauscht (von 2.6.22.18 auf 2.6.26.2) und auch das Update von Debian "Etch" nach "Lenny" vollzogen.
Stutzig wurde ich als der neue Kernel auch ein "Segfault" nach dem nächsten (verschiedene!) meldete...
Ein "memtester"-Aufruf im laufenden Betrieb unter Linux brachte sehr schnell eine Kernelpanic... Ein memtest86+ bestätigte meine Vermutung: Nach wenigen Sekunden hatte memtest86+ schon RAM-Fehler festgestellt (im Bereich um 305MB).
Nach dieser Erkenntnis habe ich den ersten RAM-Riegel ausgebaut und den 2ten in die erste Bank gesteckt. Dann nochmal einen memtest86+ und einen memtester unter Linux gemacht - alles ohne Probleme. Jetzt läuft mein Server wieder mit mageren 1000MB RAM - aber er läuft wieder.
Fazit: Auch wenn man Markenspeicher eines renommierten Herstellers verwendet kann es nach 3-4 Jahren auch zu Problemen kommen - oder die Staubschicht auf dem RAM und der RAM-Bank war etwas zu hoch ;)
Und zum Abschluss noch ein Kernel-Zitat:
"Eeek! page_mapcount(page) went negative! (-1)".
Ich habe den Linux-Kernel des Hosts auf meinem VServer-System getauscht (von 2.6.22.18 auf 2.6.26.2) und auch das Update von Debian "Etch" nach "Lenny" vollzogen.
Stutzig wurde ich als der neue Kernel auch ein "Segfault" nach dem nächsten (verschiedene!) meldete...
Ein "memtester"-Aufruf im laufenden Betrieb unter Linux brachte sehr schnell eine Kernelpanic... Ein memtest86+ bestätigte meine Vermutung: Nach wenigen Sekunden hatte memtest86+ schon RAM-Fehler festgestellt (im Bereich um 305MB).
Nach dieser Erkenntnis habe ich den ersten RAM-Riegel ausgebaut und den 2ten in die erste Bank gesteckt. Dann nochmal einen memtest86+ und einen memtester unter Linux gemacht - alles ohne Probleme. Jetzt läuft mein Server wieder mit mageren 1000MB RAM - aber er läuft wieder.
Fazit: Auch wenn man Markenspeicher eines renommierten Herstellers verwendet kann es nach 3-4 Jahren auch zu Problemen kommen - oder die Staubschicht auf dem RAM und der RAM-Bank war etwas zu hoch ;)
Und zum Abschluss noch ein Kernel-Zitat:
"Eeek! page_mapcount(page) went negative! (-1)".
Mittwoch, 15. Juli 2009
Tip: Firefox unter Linux und Backspace
Wer mal einen Windows-Benutzer an seinem Linux-Rechner gesehen hat (ja die soll es ja auch noch vereinzelt geben) dem fällt evtl. das Firefox/Backspace-Problem auf. Der Windows-Firefox-Benutzer drückt häufiger die Backspace-Taste und erwartet anscheinend den Sprung auf die vorige Seite.
Das ist per Default in der Linux-Variante des Firefox-Browsers deaktiviert. Aktiviert werden kann dieses Verhalten in "about:config" unter "browser.backspace_action". Hier einfach den Wert "0" (anstatt "2" oder >1) eintragen und fertig.
Weitere Informationen:
Das ist per Default in der Linux-Variante des Firefox-Browsers deaktiviert. Aktiviert werden kann dieses Verhalten in "about:config" unter "browser.backspace_action". Hier einfach den Wert "0" (anstatt "2" oder >1) eintragen und fertig.
Weitere Informationen:
Dienstag, 14. Juli 2009
Tip: Tomcat 5.x Encoding-Problematik...
Das Encoding-Problem ist wohl vielen bekannt - ich wollte mir auch schon ein "Schei* Encoding" T-Shirt bestellen...
Im Apache Tomcat 6 reichte bei mir immer ein
Natürlich sollte man das wie z.B. im Spring-Framework wenn möglich in einen eigenen Servlet-Filter (siehe CharacterEncodingFilter) auslagern.
Beim Tomcat 5.x hatte ich mit diesem Vorgehen leider kein Glück. Weder die Context-Konfigurationsoptionen "URIEncoding" noch "useBodyEncodingForURI" in der Konfigurationsdatei brachten Besserung. Dieses Problem hatten aber wohl schon mehrere Anwender - siehe hier.
Bisher konnte ich das Problem leider nur auf folgendem Weg lösen:
Update 14.07.2009: Ich konnte mit folgender Testseite alle drei Tomcat-Versionen:
Wirklich komisch - ich muss nochmal genau nachforschen warum das ältere Projekt im Tomcat 6.x problemlos mit dieser Variante funktionierte und bei Tomcat 5.x Probleme bereitet hatte.
Update 15.07.2009: Das Rätsel ist gelöst! eine jar-Datei hat zu diesem Phänomen bei dem alten Projekt geführt. In meinem Fall eine jar-Datei des CMS FirstSpirit namens "fs-access.jar". Wenn diese aus dem "WEB-INF/lib"-Verzeichnis entfernt wird und "setCharacterEncoding" verwendet wird funktioniert auch im Tomcat 5.x alles wie erwartet. Evtl. ist die "fs-access.jar" in diesem Fall eine veraltete Version. Warum der Tomcat 5.x damit ein Problem hat und der Tomcat 6.x nicht ist mir aber immer noch ein Rätsel.
Update 15.07.2009 / 2: Die Kontext-Konfiguration "URIEncoding" wirkt sich nur auf das URI-Encoding aus! d.h. das muss verwendet werden wenn man die Parameter z.B. im Querystring übergibt (HTTP-Methode GET). Wenn das in der server.xml konfiguriert wurde kann man sich das Umwandeln von "ISO-8859-1"-Zeichenfolgen nach "UTF-8" sparen.
Weitere Informationen:
Im Apache Tomcat 6 reichte bei mir immer ein
request.setCharacterEncoding("UTF-8");
bei folgendem Seitenkopf in der JSP <%@ page pageEncoding=”UTF-8″ contentType=”text/html; charset=UTF-8″%>und ich konnte die Anfrageparameter in UTF-8 ohne Probleme auslesen.
Natürlich sollte man das wie z.B. im Spring-Framework wenn möglich in einen eigenen Servlet-Filter (siehe CharacterEncodingFilter) auslagern.
Beim Tomcat 5.x hatte ich mit diesem Vorgehen leider kein Glück. Weder die Context-Konfigurationsoptionen "URIEncoding" noch "useBodyEncodingForURI" in der Konfigurationsdatei brachten Besserung. Dieses Problem hatten aber wohl schon mehrere Anwender - siehe hier.
Bisher konnte ich das Problem leider nur auf folgendem Weg lösen:
String firstname = request.getParameter("firstname");
if (firstname != null) {
firstname = new String(firstname.getBytes("ISO-8859-1"),"UTF-8");
}In diesem Fall konvertiere ich den Parameter von "ISO-8859-1" nach "UTF-8". Das sollte laut Tomcat FAQ auch kein Problem darstellen, da das Default-Encoding bei Servlets laut dem FAQ auch "ISO-8859-1" sein sollte:Default Encoding for POST
ISO-8859-1 is defined as the default character set for HTTP request and response bodies in the servlet specification (request encoding: section 4.9 for spec version 2.4, section 3.9 for spec version 2.5; response encoding: section 5.4 for both spec versions 2.4 and 2.5). This default is historical: it comes from sections 3.4.1 and 3.7.1 of the HTTP/1.1 specification.
Update 14.07.2009: Ich konnte mit folgender Testseite alle drei Tomcat-Versionen:
- 5.0.28
- 5.5.27
- 6.0.20
Wirklich komisch - ich muss nochmal genau nachforschen warum das ältere Projekt im Tomcat 6.x problemlos mit dieser Variante funktionierte und bei Tomcat 5.x Probleme bereitet hatte.
Update 15.07.2009: Das Rätsel ist gelöst! eine jar-Datei hat zu diesem Phänomen bei dem alten Projekt geführt. In meinem Fall eine jar-Datei des CMS FirstSpirit namens "fs-access.jar". Wenn diese aus dem "WEB-INF/lib"-Verzeichnis entfernt wird und "setCharacterEncoding" verwendet wird funktioniert auch im Tomcat 5.x alles wie erwartet. Evtl. ist die "fs-access.jar" in diesem Fall eine veraltete Version. Warum der Tomcat 5.x damit ein Problem hat und der Tomcat 6.x nicht ist mir aber immer noch ein Rätsel.
Update 15.07.2009 / 2: Die Kontext-Konfiguration "URIEncoding" wirkt sich nur auf das URI-Encoding aus! d.h. das muss verwendet werden wenn man die Parameter z.B. im Querystring übergibt (HTTP-Methode GET). Wenn das in der server.xml konfiguriert wurde kann man sich das Umwandeln von "ISO-8859-1"-Zeichenfolgen nach "UTF-8" sparen.
Weitere Informationen:
Freitag, 29. Mai 2009
Dienstag, 28. April 2009
Kleine Warnung vor Ubuntu 9.04...
alle die daran denken das neue Ubuntu 9.04 verwenden zu können sollten lieber noch etwas warten (@Sven: man sollte also wirklich besser etwas länger warten). Auf meinem System wurde schon das zweite Mal die EXT3-Partition unschön verunstaltet - und das in einer Woche!
Womöglich handelt es sich um diesen Fehler. Ich werde jetzt mal wieder einen Kernel der 2.6.27er-Serie verwenden um zu prüfen ob man dann wieder vernünftig arbeiten kann...
Update 02.05.2009: das Problem ist bis jetzt mit einem Kernel der Serie 2.6.27 (Version 2.6.27-14) nicht mehr aufgetreten. Der neue Kernel 2.6.28-11 scheint das Problem verursacht zu haben.
Update 15.06.2009: ich habe jetzt gute Erfahrungen mit dem Kernel 2.6.29 gemacht. Diesen kann man hier finden. Das Problem scheint aber in Verbindung mit der WLAN-Karte zu stehen - bei einem normalen Rechner hatte ich bisher keinerlei Probleme mit dem 2.6.28er Kernel. Ich habe eine "Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)" in meinem Thinkpad. Weitere Infos bzgl. 2.6.29er-Kernel und Intel WLAN-Karten findet man hier.
Womöglich handelt es sich um diesen Fehler. Ich werde jetzt mal wieder einen Kernel der 2.6.27er-Serie verwenden um zu prüfen ob man dann wieder vernünftig arbeiten kann...
Update 02.05.2009: das Problem ist bis jetzt mit einem Kernel der Serie 2.6.27 (Version 2.6.27-14) nicht mehr aufgetreten. Der neue Kernel 2.6.28-11 scheint das Problem verursacht zu haben.
Update 15.06.2009: ich habe jetzt gute Erfahrungen mit dem Kernel 2.6.29 gemacht. Diesen kann man hier finden. Das Problem scheint aber in Verbindung mit der WLAN-Karte zu stehen - bei einem normalen Rechner hatte ich bisher keinerlei Probleme mit dem 2.6.28er Kernel. Ich habe eine "Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)" in meinem Thinkpad. Weitere Infos bzgl. 2.6.29er-Kernel und Intel WLAN-Karten findet man hier.
Freitag, 17. April 2009
Tip: MySQL - Linux, Windows, Mac OS - Tabellennamen
üble Sache: bei der MySQL auf Windows oder Mac OS-Systemen spielt die Groß- und Kleinschreibung der Tabellen (per Default) keine Rolle. Auf einem Linux-System aber schon! Wenn man also ein Datenbank-Abzug (mysqldump) auf einem Mac OS oder Windows macht und spielt es auf einem Linux-System ein kommt es unter Umständen zu Problemen (u.a. Tabellennamen in Constraints).
Das musste ich kürzlich auch erfahren - Gruß an Frank ;)
Mein Tip: immer die Tabellennamen und Spalten komplett in Kleinschreibung realisieren. Man kann auch mit der Variablen lower_case_table_names experimentieren.
Weitere Informationen:
Das musste ich kürzlich auch erfahren - Gruß an Frank ;)
Mein Tip: immer die Tabellennamen und Spalten komplett in Kleinschreibung realisieren. Man kann auch mit der Variablen lower_case_table_names experimentieren.
Weitere Informationen:
Abonnieren
Posts (Atom)
Posts
