-su: fork: Nicht genügend Hauptspeicher verfügbar

Ich hab grad mal postfix mit amavisd installiert .. konfigurieren kann ich ihn jetzt nicht mehr, vi läßt ja nicht mehr starten, weil nicht genügend Hauptspeicher vorhanden ist.

Aus unerfindlichen Gründen habe ich vor einiger Zeit die Suche nach einem vernünftigen Netzwerk-Manager für Linux intensiviert. Der Gnome Network Manager kam dabei für mich nicht in Frage, da ich das Tool für sehr rudimentär erachte. Es sollte schon eine Applikation sein, welche mehrere Netzwerk-Verbindungen/-Profile vernünftig verwalten kann, egal ob W-LAN oder Kabel-LAN. So bin ich dann auf wicd gestoßen.

wicd ist ein Python-Script mit graphischer Oberfläche und Tray-Icon. Das Tool setzt auf dbus auf und überwacht darüber die Netzwerk-Devices. Es zeigt verfügbare W-LANs an, inklusiver der unterstützten Verschlüsselungs-Mechanismen. Dabei kann man sich auch zu versteckten W-LANs über Eingabe einer bekannten SSID verbinden. Für Debian/Ubuntu sind Pakete im Netz und meines Wissens auch in den Repositories zu finden. Leider findet sich in portage noch kein Paket, ein eBuild für Version 1.3.1 kann man aber hier finden.

Wie aus dem eBuild ersichtlich, und schon erwähnt, benötigt wicd Dbus, welcher als Daemon auch aktiv sein muß. Dazu benötigt der Netzwerk Manager noch mehrere Python-Pakete, u.a. dev-python/pygtk, dev-python/pygobject, dev-python/pycairo und, was bisher nirgends zu lesen war, scheinbar notwendigerweise auch dev-python/dbus-python, ansonsten spuckt das Tool

ImportError: No module named dbus

beim Start aus. Ein Eintrag in der Autostart-Sektion von KDE startet dann auch direkt das Tray-Tool, womit man bequem Zugriff auf die Konfiguration erhält. Das Tray-Icon beinhaltet auch Information per Tooltip über die aktuelle Verbindung/-squalität. Den Zugriff auf das Tray-Tool erhält man über

/opt/wicd/tray.py

Irgendwie scheinen sich aber wicd und Knemo nicht miteinander zu vertragen – seit der Installation vom Netzwerk Manager läßt sich der Knemo-Daemon nicht mehr durch KDE starten.

Ein System, welches stetig mit der aktuellen Entwicklung wächst und keine Release-Stände “einfriert” ändert sich entsprechend häufig. So ändern sich die Konfigurationen, Abhängigkeiten oder eben auch Startscripte. Diesmal betraf es bei einem meiner letzten Updates unter Gentoo die splashutils. Beim Booten bekam ich die Fehlermeldung:

rc: WARNING: /etc/init.d/splash missing; skipping ...

Hintergrund war, daß der Bootsplash, btw die Terminals tty2 bis tty6 nicht mehr mit dem Splash-Theme versehen wurden. Ist letztlich auch kein Wunder, wenn das nötige Script nicht ausgeführt wird.

Wenn man wenigstens etwas genauer die Meldungen am Ende eines Update-Vorgangs von portage lesen würde, dann wüßte man aber auch, daß das Init-Script nicht mehr splash heißt, sondern seit den splashutils-1.5.2.1 eben fbcondecor.

Also einfach die entsprechende Scripte mittels rc-update austauschen und sich freuen.

Seit meinen Anfangstagen mit Linux bin ich kein besonderer Freund von RPM-Distributionen. Die Dependency-Hell hat zu sehr ihre Spuren hinterlassen, auch wenn das heutzutage dank YUM und Konsorten kein wirklich elementares Thema mehr ist. So beschränken sich meine Kontakte mit SuSE- oder RedHat-Derivaten auf das Nötigste – meist auf die Arbeit.

Im Grunde ist es eigentlich auch nicht mal ein richtiges (Open)SuSE-eigenes Problem, sondern vielmehr vom Apache-Projekt hausgemacht. Die Konfigurations-Datei httpd.conf vom Apache httpd ist – vorsichtig ausgedrückt – umfangreich. Deswegen splitten die Maintainer unter OpenSuSE die Konfiguration in übersichtliche Teildateien, welche dann auch bequem mittels Yast bearbeitet werden können.

Aber ehrlich – so ganz blick ich das Konzept hinter den einzelnen, aufgesplitteten Teildateien immer noch nicht – auch wenn in der httpd.conf quasi eine Liste aller Dateien und ihrer Abhängigkeiten aufgeführt ist. Denn so ganz will mir die Unterscheidung zwischen httpd.conf und default-server.conf schon nicht in den Kopf. Wer läßt denn mehr als einen Apache httpd gleichzeitig auf einem System laufen?

Von der durchaus zweifelhaften Menüführung durch die HTTP-Server-Konfiguration im “Konsolen-YaST” möcht ich auch nicht groß sprechen.
vi /etc/apache2/httpd.conf ist da eher mein Freund.

Wo ich mich aber grade auch so weit aus dem Fenster lehne: Mein geliebtes Gentoo splittet die Apache-Konfiguration auch in mind. zwei Dateien. Unter anderem /etc/conf.d/apache für das Laden der benötigten Module. Definitiv suboptimal – auch wenn dort klar nur die wesentlichen Konfigurationen wie Module, DocumentRoot und Ort der Konfigurations-Datei erwartet werden.

Aber die mehrere, hundert Zeilen lange Konfiguration des Apache Bedarf dringend einer Überarbeitung. Sonst steuern bald 100kB große Text-Dateien vornehmlich mit Kommentaren das Verhalten eines einzelnen Webservers.

Mein Fileserver scratchy ist und bleibt mein Sorgenkind: Das liegt zum einen an der sehr betagten Hardware und an der 24/7-Beanspruchung, wofür die verbauten Komponenten nie ausgelegt waren. So hat sich in der Nacht von Mittwoch auf Donnerstag das System aufgehangen. Die Debug-Meldung schien mir irgendwas von parport erzählen zu wollen. Jedenfalls fror das System ein und … ließ sich auch nicht mehr booten.

Nach “Verifying DMI Pool Data ...” wurde der Bootloader nicht aufgerufen. Abends konnte ich das System dann endlich zerlegen und die Hardware prüfen. Das Netzteil ist defekt und der CPU-Lüfter hatte sich mittlerweile auch fest gelaufen und wollte die CPU partout nicht mehr kühlen. Nach einiger Zeit des Testens bin ich zu dem unweigerlichen Entschluß gekommen: Machen wir mal ‘n Filesystem-Check und installieren grub neu.

Das war jedenfalls erfolgreich und scratchy “schnurrt” wieder brav vor sich hin. Ich hoffe, endlich mal länger als 75 Tage am Stück. Der Umzug in die andere Ecke vom Keller scheint dem Rechner bisher noch nicht so recht bekommen zu sein.