Mal wieder : W: GPG error: http://ftp.de.debian.org etch Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

Mal wieder gab’s beim Update per apt-get die berüchtigte Fehlermeldung mit dem Public-Key. Da auf der Webseite, die ich letztens angegeben hatte, anscheinend nicht der aktuelle Schlüssel liegt, habe ich gegoogelt und unter http://www.gestreift.net/content/view/29/27/ die passende Lösung gefunden, die hoffentlich auch auf Dauer hilft…

 

Apache 1.3: child pid ddddd exit signal Segmentation fault (11)

Um das Netzwerkkarten-Problem mit dem PE 2850 unter SLES 9 zu lösen, empfahl Dell ja, das neueste Service Pack von SuSE einzuspielen. Dies hatte ich erfolgreich getan. Alles lief auf dem Rechner, bis jetzt traten die Netzwerkkarten-Probleme nicht wieder auf.
Aber: Plötzlich traten beim Apache 1.3 auf ganz bestimmten php-Seiten Abstürze auf. Im error_log fanden sich Einträge der Art
child pid ddddd exit signal Segmentation fault (11)
Diese Fehler waren immerhin reproduzierbar. Zunächst dachte ich, dass bei den Updates eine Library, gegen die der Apache, PHP oder mod_perl gelinkt waren, ausgetauscht wurden und nun die Probleme verursachen. Als aber eine neue Kompilierung dieser drei Bausteine nichts brachte, war guter Rat teuer.
Ich versuchte dann, den Apache dazu zu bewegen, einen Coredump in ein core file zu schreiben. Ich habe also zunächt per ulimit -c unlimited für root die maximale Größenbeschränkung aufgehoben. Der Apache weigerte sich aber nach wie vor, sein core file zu schreiben. Daraufhin habe ich den Prozess als normaler Nutzer ohne uid-Wechsel laufen lassen (an einem Port >1024 natürlich) und für diesen Nutzer das Limit aufgehoben. Wieder ohne Erfolg. (Wenn mir jemand sagen kann, wie zu dem core file komme, würde ich mich freuen.)
Also Griff ich dann zum gdb. Zunächst startete ich den Apache mit der Option -X, um ihn im Vordergrund laufen zu lassen. Per gdb -p konnektierte ich mich an den Prozess (später versuchte ich es auch per run -X -f httpd.conf innerhalb es gdb mit dem gleichen Effekt). Ich rief die Fehler-produzierende Seite auf und erhielt die Meldung
Cannot find user-level thread for LWP ddddd: capability not available
Wie ich mich drehte und wendete, ich kam nicht an die Fehler.produzierende Library…
Plötzlich kam mir die Idee, dass LWP Light Weight Process, also Threads heißen könnte. Da fiel mir ein, dass ich doch gerade was im SAP-Hinweis 171356 darüber gelesen hatte und dass man über die Umgebungsvariable LD_ASSUME_KERNEL=2.4.1 auf die alte Variante zurückschalten kann. Gesagt, getan, und der Apache lief wieder ohne Fehler.

Remote X11 bei Debian etch

Die Tage benötigte ich einen Xserver auf meinem Windows-Rechner. Also habe ich mein Debian unter VMware gestartet. Aber aus Sicherheitsgründen ist dieser Xserver standardmäßig nicht remote über das Netz zu erreichen. (netstat -taln zeigt keinen Prozess an, der an Port 6000 lauscht.)
Immerhin wusste ich von früheren Problemen dieser Art, dass dies irgendwas mit der Option nolisten tcp zu tun hat. Also habe ich mich auf die Suche gemacht.
In der Datei /etc/kde3/kdm/Xservers hatte ich schon seinerzeit diese Option auskommentiert. aber es funktionierte noch immer nicht.
Schließlich fand ich die Datei /etc/kde3/kdm/kdmrc. Dort kommentiert man die Zeile ServerArgslocal=-nolisten tcp aus, startet den kdm neu, und schon ist der Xserver von außen zu erreichen.
Mir ist auch klar, dass in Zeiten von X11Forwarding der ssh die Variante mit xhost + etwas sehr freizügig ist. Ich hatte aber mal wieder das Problem, dass bei einer SAP-Installation per SAPInst das GUI nicht seinen Installationsprozess gefunden hat, wenn nicht explizit per DISPLAY-Variable der Xserver angegeben wurde. Auch ein Zugriff per vnc brachte nicht die Lösung. Dieses Problem ließ sich früher dadurch lösen, dass man auf die uralte Methode per Telnet und DISPLAY-Variable das Programm gestartet hat.
Diesmal führte aber auch dies nicht zum Erfolg. Die Lösung ist viel einfacher: Das GUI schlägt localhost und Port 21212 vor. Ersetzt man localhost durch den richtigen Hostname, läuft’s ….

Google-Toolbar der Übeltäter ?

Nachdem ich unter VMware den riesigen Speicherverbrauch reproduzieren konnte, indem ich mein Profil dorthin kopiert habe, habe ich alle Erweiterungen deinstalliert. Aber noch immer nahm der Speicherverbrauch große Dimensionen an und der Firefox wurde immer langsamer.
Daraufhin habe ich mich entschlossen, mein Profil zu löschen und neu anzulegen. Meine Bookmarks habe ich noch über den Lesezeichenmanager exportiert und dann wieder im neuen Profil importiert. Dabei fiel mir schon auf, dass die Bookmarks in der Bookmarkleiste weg waren — waren sie zwar nicht, sie waren nur woanders. Das Ding heißt nun Lesezeichen-Symbolleiste. Bei mir lag noch alles im Bookmarks Toolbar Folder.
Aber meine gesammelten Passworte sind weg. Ich habe auf die Schnelle keine Möglichkeit gefunden, diese zu ex- und wieder zu importieren.
Mir fiel aber auf, dass nach dem Deinstallieren aller Erweiterungen immer noch ein Ordner der Google-Toolbar in meinem Profil lag. Ich weiß also nicht, in wie weit die Deinstallation komplett war. Zeitlich kommt es auch ungefähr hin: Seit ich sie installiert hatte, traten die Probleme auf.
Wie dem auch sei, war ich nun recht sparsam mit dem Installieren von Erweiterungen!

Speicherverbrauch bei Firefox 1.5 extrem hoch

Seit einiger Zeit frisst bei mir der Firefox extrem viel Speicher. Okay, ich habe auch immer 10 bis 20 Tabs offen. Aber trotzdem kann ich mir folgendes Verhalten nicht recht erklären:
Laut Taskmanager steht die Auslagerungsdatei bei 1.4GB. Ich schließe den Firefox. Nach einigem Gerödel auf der Festplatte hat er sich dann auch beendet. Dann ist die Auslagerungsdatei nur noch 400 MB groß. Firefox frisst also 1GB ! Öffne ich dann sofort wieder meinen Firefox, lädt er dank SessionSaver alle Tabs wieder nach und verbraucht nur 30 bis 40 MB.

"Okay", dachte ich, "eine der zig Erweiterungen ist die Ursache." Starte ich den Firefox im SafeMode, so ist das Arbeiten ohne meine Erweiterungen sehr mühsam (wenn man sich erst mal an die MouseGestures gewöhnt hat …). Daher kann ich so adhoc nicht sagen, ob der Effekt noch auftritt. Völlig weg scheint er nicht zu sein. Daher gehe ich nun den anderen Weg: Ich versuche unter VMware das ganze in der Hoffnung zu reproduzieren, dass ich dort dann in aller Ruhe die Ursache ermitteln kann. Sei es, das Profil zu löschen, sei es, Erweiterungen nachzuinstallieren…
Mit den Hinweisen, die man per Google so findet, dass der Firefox halt speicherhungrig ist, gebe ich mich zumindest jetzt noch nicht zufrieden. Das war früher nicht so extrem…..