Anders als bei einem Absturz gibt es keinen definierten Fehlerzeitpunkt, wenn  sich ein Programm aufhängt. Der Computer (und auch der Bediener) kann nie entscheiden zwischen “das Programm rechnet einfach mal ein wenig” und “das Programm hängt in einer Endlosschleife”. Deshalb ist es schwierig, einen Backtrace automatisiert erstellen zu lassen.

Momentan haben wir in der Pidgin-Community das Problem, dass sich Pidgin manchmal aufhängt. Dieser Fehler tritt ziemlich selten auf und meist dann, wenn man ein paar Stunden nicht am PC war…also ist er recht schwierig zu finden.

Jedenfalls, falls sich Pidgin mal wieder aufhängt, ist das zu tun:

1. die Prozess-ID (PID) ermitteln (z.B. mit top oder irgendeinem anderen “Taskmanager”); der hängende Prozess sollte der einzige sein, der einen CPU-Kern komplett auslastet
2. den genauen Pfad der Anwendung ermitteln: which pidgin
3. gdb als root starten (Begründung) mit sudo gdb <Pfad> (sudo ist Distribution-spezifisch, ich weiß…hier hilft ggf. mitdenken )
4. attach <PID> eingeben um sich an den Prozess anzuhängen. Dieser sollte jetzt angehalten werden und die CPU-Auslastung sinken.
5. bt full eingeben und die Ausgabe an einen Fachkundigen schicken
6. mit kill das Programm beenden und mit quit den gdb verlassen.

So, und jetzt hoffe ich, dass wir der Sache auf die Schliche kommen, blubby.

Zum Testen habe ich ein kleines Plugin geschrieben. Es hängt Pidgin auf, wenn es aktiviert wird. Natürlich sollte es nicht in produktiven Umgebungen eingesetzt werden.

Angehängte Dateien:

• Pidgin HangUP (57)

Im Internet (Quellenangabe, aktuelles Thema) habe ich den Hinweis gefunden, dass man es doch einmal mit dem Madwifi-Treiber versuchen sollen, was dann auch zum Erfolg führte. Da sich die Madwifi HAL 0.10.5.6 unter Maverick nicht mehr kompilieren lässt, hier die dezent abgewandelte Anleitung:

Zunächst muss der Madwifi-Treiber heruntergeladen, kompiliert und installiert werden:

sudo apt-get install linux-headers-$(uname -r) build-essential
wget http://snapshots.madwifi-project.org/madwifi-0.9.4/madwifi-0.9.4-r4136-20110203.tar.gz
cd madwifi-0.9.4-r4136-20110203/
make
sudo make uninstall
sudo make install

Anschließend den ath5k deaktivieren und stattdessen den Madwifi aktivieren. Dazu wird die Datei /etc/modprobe.d/blacklist-ath_pci.conf (als root) editiert, sodass hinterher folgendes drin steht:

#blacklist ath_pci
blacklist ath5k

Jetzt noch ein Neustart und die Sache müsste laufen.

Wie dem auch sei – jetzt habe ich wieder zwei Rechner. Und mittlerweile kann man ja wirklich alles synchronisieren: Lesezeichen (und sogar selbst definierte Suchmaschinen) kann der Opera von sich aus. E-Mails sind klar – hier hat sich seit Jahren IMAP etabliert und ich hab zum Glück keine POP3-Accounts mehr. (Trotzdem kenne ich jemanden, der POP3 sogar vorzieht, aber begründen kann er das leider nicht.) Was bleibt sind die Newsfeeds und die Chatlogs. Für letztere suche ich noch nach einer praktikablen Lösung.

Bisher habe ich immer den Opera für die Feeds verwendet, allerdings können diese (vermutlich aufgrund der vielen Änderungen) nicht synchronisiert werden. Mit “synchronisieren” meine ich nicht nur, welche Feeds abgerufen werden sondern auch welche bereits gelesen wurden – sonst hab ich immer eine ganze Latte ungelesener Nachrichten und das ist auch nicht gut. Ich habe mich ein wenig umgeschaut und als einzige einigermaßen sinnvolle Lösung erschien mir das kleine Programm feed2imap für Linux. Dieses Tool fragt alle Feeds ab und erstellt ungelesene E-Mails in einem IMAP-Konto. Dabei erzeugt es die E-Mails direkt in einem, für jedes Feed separat einstellbaren, Unterordner des E-Mail-Accounts. Einen Nachteil hat die Lösung allerdings: man braucht einen Linux-Rechner, der ständig online ist (den ich zum Glück habe).

Zunächst galt es, einen passenden E-Mail-Account zu finden. Ich wollte gerne einen separaten Account haben, weil ich den dann im Thunderbird einfach einklappen kann, wenn er mich mal nicht interessiert. Es ist gar nicht so einfach, einen Freemailer ohne Werbung, mit IMAP und auch noch mit Unterstützung für Unterordner zu finden. Aber www.eml.cc schafft es, diese drei Wünsche auf einmal zu erfüllen. Und ist dabei sogar relativ schnell im Zugriff. (Ich habe einige andere Hoster ausprobiert…)

Bleibt noch das Einrichten von feed2imap. Da ich auf meinem Server ein Debian einsetze und das Programm in den Repositories vorhanden ist, reicht ein einfaches apt-get install feed2imap zur Installation. Die Konfigurationsdateien sehen ein wenig merkwürdig aus und lassen sich jetzt hier im WordPress auch nicht richtig formatieren, weshalb ich einfach eine Beispieldatei an den Artikel anhänge. Wie man darin sieht, sind für jedes Newsfeed drei Zeilen vorgesehen, die eigentlich selbsterklärend sind.

In den Zeilen target sieht man einige Besonderheiten, die www.eml.cc beim Zugriff über IMAP hat. Zum einen muss der Login-Name die Domain, durch ein Gleichheitszeichen = getrennt, enthalten. Ich vermute, dass der Hoster mehrere Domains auf dem Server mail.messagingengine.com vereint. Zum anderen werden keine Schrägstriche sondern Punkte als Trenner von Verzeichnisnamen benutzt. Meine Feeds sollen also alle im IMAP-Verzeichnis INBOX/Feeds/MCN landen, das ich vorher in meinem Mail-Programm angelegt habe.  Das Passwort muss natürlich auch angelegt werden, aber das ist klar, glaube ich. In den Einstellungen von www.eml.cc kann man übrigens einstellen, dass das Feeds-Verzeichnis auf derselben Stufe wie der Posteingang angezeigt wird, obwohl das eigentlich falsch ist.

Nun ist es natürlich ein wenig umständlich, feed2imap ständig von Hand zu starten, also habe ich mir einen cronjob angelegt. Okay, mehrere – da ich relativ viele Feeds verfolge, habe ich sie in drei Gruppen geteilt: eine deren Feeds alle fünf Minuten abgerufen werden und je eine für die Feeds, die alle 60 bzw. 180 Minuten geprüft werden sollen. Meine Crontab sieht zum Beispiel so aus: (insgesamt sind es fünf Zeilen, die kurzen gehören noch zur jeweils letzten…)

# m h dom mon dow command
*/5 * * * * /usr/bin/feed2imap -f /home/kgraefe/.feed2imap/5mins > /dev/null 2>&1
2 * * * * /usr/bin/feed2imap -f /home/kgraefe/.feed2imap/60mins > /dev/null 2>&1
7 */3 * * * /usr/bin/feed2imap -f /home/kgraefe/.feed2imap/180mins > /dev/null 2>&1
#*/5 * * * * /usr/bin/feed2imap > /dev/null 2>&1

Was die einzelnen Zeilen zu bedeuten haben, kann jeder mit Hilfe des Wiki-Artikels selbst herausfinden. Mein Artikel ist eh schon viel zu lang, wie ich finde.

Nun kann man bequem von jedem Rechner aus auf das E-Mail-Konto zugreifen und ungelesene Newsfeeds lesen und für alle anderen Rechner als gelesen markieren (bzw. löschen). Man sollte natürlich alle Ordner auf neue Nachrichten überprüfen lassen.

Gute Nacht.

Angehängte Dateien:

feed2imaprc (180)

Was war passiert? Ich hatte am Vorabend den Webspace per smbmount nach /tmp/www gemountet, weil ich ein paar Änderungen vorgenommen habe. Am nächsten Morgen wollte ich meinen Rechner einpacken und musste den Webspace unmounten. In einem der Terminals stand folgendes:

kgraefe@sardes:~> smbumount /tmp/www
kgraefe@sardes:~>

Also war ich davon ausgegangen, dass dies bereits geschehen ist… Da ich ein ordentlicher Mensch bin (haha), hab ich natürlich gleich den Mountpoint gelöscht:

kgraefe@sardes:~> rm /tmp/www
rm: Entfernen von „/tmp/www“ nicht möglich: Is a directory
kgraefe@sardes:~>

“Ok“, dachte ich mir, “es ist ein Verzeichnis, also rm -r.” – tja, das hat etwas gerödelt um sich dann zu beschweren, dass irgendeine Datei wohl schreibgeschützt wäre. Ihr könnt euch vorstellen, dass ich erstmal 2 Minuten mit offenem Mund auf den Bildschirm gestarrt habe – ein toller Start in den neuen Monat. Warum die Freigabe nicht abgehängt war kann ich jetzt nicht mehr genau sagen, wahrscheinlich habe ich irgendwie Strg+C gedrückt oder sowas.

Wie hätte man das verhindern können? Ähm, mit Windows wär’ das nicht passiert: einfach Rechtsklick und “Trennen” auswählen und  die Sache ist gegessen. Unter Linux sollte man sich angewöhnen, zum Löschen von leeren Verzeichnissen (z.B. eben Mountpoints) *immer* rmdir zu benutzen, da das im Gegensatz zu ‘rm -r‘ Alarm schlägt und abbricht, falls das Verzeichnis doch nicht leer ist. Mir war der Sinn dieses Tools bisher immer schleierhaft – seit Mittwoch kenne ich ihn.

Wie ging es weiter? Das Rechenzentrum macht zum Glück täglich Backups und war so freundlich, die Seite sogar noch vor dem Mittagessen wiederherzustellen. (Ob der Herr Luehr namentlich genannt werden will? Hm.) Danke nochmal dafür.

Man soll ja aus Fehlern anderer lernen…also…nehmt rmdir.
Und tschüss.