Heute will ich mal eine kleine Serie über haarsträubende Bugs rund um Linux starten. Der Aktuelle hat mich jetzt vier Stunden Frei- und sicher vier Wochen Lebenszeit gekostet.
Alles fing damit an, dass nautilus - der Dateimanager des GNOME-Desktops nicht mehr starten wollte. Mehr als ein Taskleisteneintrag (etwa 20 Sekunden) war dem Ding nicht zu entlocken und auch gdb und strace brachten nichts Verwertbares. Da Nautilus mit einem anderen Benutzerprofil und auch als root (mittels gksudo) startete, lag es wohl nicht am Programm selbst, sondern an irgendeiner Einstellung und/oder Datei oder Rechten in meinem Homeverzeichnis.
Als ich nach knapp vier Stunden so ziemlich alles gesichert, ausgetauscht, gelöscht, chown-ed, etc. habe was auch nur entfernt mit Nautilus oder GNOME zu tun hat, fiel mir eine SVG-Grafikdatei auf dem (ebenso eingefrorenen) Desktop auf welche anstatt der Minivorschau nur eine Uhr zeigt wie sie sichtbar ist, solange die Vorschau nicht erstellt wurde. Was soll ich sagen? Datei weggesichert, vom Desktop gelöscht und TADA: Nautilus funktioniert wieder. Witzigerweise auch nachdem ich die Datei wieder zurückkopiert habe. fsck brachte keine Fehler im Dateisystem und die Datei selbst war auch in Ordnung, so dass ich nach wie vor keine Ahnung habe warum das passiert ist. Ich muss wohl nicht extra dazu sagen, dass der Bugtracker von Ubuntu/Fedora/Gnome/younameit voll ist von entsprechenden Einträgen, die aber allesamt andere Ursachen haben. Scheinbar ist es das Standardverhalten von nautilus bei Problemen einfach mal genau nichts zu tun.
Ich frage mich ernsthaft warum man so einen Fehler nicht abfangen oder wenigstens redseliger behandeln kann. Da kommt doch keine Sau drauf.
Man zeige mir nen Apple der das mitmacht :)
Wie man vielleicht sieht, bin ich nach zwei Wochen Ausflug nach KDE wieder zu XFCE zurückgekehrt. Es geht einfach nix drübba.
Letztens war es wieder so weit: Bei meinem Internetanbieter war Rush-hour und trotz dicker Leitung kommt man sich vor wie Mitte der Neunziger. Antwortzeiten von mehreren Sekunden verderben einem gründlich den Spass am surfen.
Ein paar Tests später kam ich dahinter, dass die DNS-Server des Anbieters unglaublich träge antworteten. War der Host erst einmal aufgelöst oder vom Browser gecached ging es recht fix weiter. Also was machen wenn so etwas wieder passiert?
Hier kommt ein einem dnsmasq gerade recht. Es handelt sich um einen ultraschlanken DNS- und/oder DHCP-Server, der, einmal eingerichtet, mein gesamtes kleines Heimnetzwerk mit DNS-Auflösung versorgen kann.
Wie unter Archlinux üblich ist so etwas auch schnell eingerichtet. Mit pacman -Sy dnsmasq installiert man sich das Paket (gerade einmal 110 K schwer) und kann sich an's Einrichten in /etc/dnsmasq.conf machen:
# Or which to listen on by address (remember to include 127.0.0.1 if
# you use this.)
listen-address=127.0.0.1
listen-address=192.168.178.2
Das war's eigentlich auch schon: Wer will kann die Anfragen noch mitloggen oder den eingebauten DHCP-Server nutzen. Mir hat die DNS-Cache-Funktionalität genügt und so habe ich einfach die listen-address-Direktiven an mein Netzwerk angepasst: 127.0.0.1 damit der Server (mein NAS übernimmt das) bei sich selbst nachfragen kann und 192.168.178.2 (Die IP auf die eth0 hört) damit auch der Rest davon was hat.
Die upstream-Server bezieht dnsmasq standardmässig aus der vorhandenen /etc/resolv.conf, so dass es Sinn macht diese anzupassen:
# /etc/resolv.conf.head can replace this line
search haggy.org
# Route DNS requests through dnsmasq first
nameserver 127.0.0.1
# Fritzbox
nameserver 192.168.178.1
# First OpenDNS server
nameserver 208.67.222.222
# Second OpenDNS server
nameserver 208.67.220.220
# /etc/resolv.conf.tail can replace this line
Drei Fallbacks sollten genügen. Abschliessend den daemon mit /etc/rc.d/dnsmasq start starten und nicht vergessen diesen auch in das DAEMONS=() -Array in /etc/rc.conf aufnehmen, um ihn beim nächsten Reboot gleich mitzustarten.
Das Ergebnis kann sich sehen lassen - von rund 300 msec und mehr bei langsamen DNS-Anfragen auf ca. 1 msec bei jedem weiteren Aufruf. Das fühlt sich doch sofort auch schneller an.
Wer schon immer davon genervt war, bei sudo-Kommandos alle paar Minuten sein Passwort neu eingeben zu müssen, der kann die Zeitspanne, die sudo abwartet bis es erneut nach dem Passwort fragt auch deutlich verlängern (oder nicht-empfohlenerweise auf unendlich setzen).
Man bearbeite hierzu seine sudoers mit
$ sudo visudo
und füge folgende Zeile irgendwo an den Anfang ein
Defaults timestamp_timeout=60
Das hier setzt das Timeout auf eine Stunde.