Archiv für den Monat: September 2015

Allgemein

„GLib-CRITICAL“ Seltsamer Ubuntu Bug oder seltsame Fehlermeldung?

Ein Kommentar

gparted-logoUbuntu 15.04 hat bisher problemlos funktioniert, aber leider ist jetzt seit Tagen eine Fehlermeldung beim Startvorgang aufgetaucht, die mich beunruhigte.
„GLib-CRITICAL: Source ID 13 was not found when attempting to remove it“ steht in der syslog.
Angeblich ein Bug, der bei mir auch reproduzierbar ist. Bekannt geben brauche ich ihn nicht mehr, da er schon auf bugs.launchpad.net zu finden ist, siehe GLib-CRITICAL **: Source ID was not found when attempting to remove it – warning when leaving Network menu of g-c-c.
Da ich ein start fähiges Ubuntu auf einem USB-Stick habe und mein „home“ und „etc“ gesichert ist, kann nicht viel passieren, also sehe ich mir einmal die Laufwerke mit e2fsck(8) an, wie es beim Bootvorgang empfohlen wird. Dieser wird angehalten, dann kommt die Meldung: „Welcome to emergency mode! After logging in type „journalctl -xb …. usw. Ja, da steht das Gleiche, wie in der syslog: „GLib-CRITICAL **: Source ID was not found w“… und zur Behebung bekam ich vom System den Tipp, ich solle e2fsck ausführen. Das kann zwar nicht schaden, aber da ich gerade keine Lust dazu hatte, wollte ich Fedora starten und stellte zu meinem Entsetzen fest, dass ich letztes mal nur Ubuntu, Mint und Windows 9 installierte. Windows bekam ich kostenlos von einem Institut und Mint ist bestimmt auch sehr gut, aber mir persönlich gefällt es nicht besonders. Das ist aber nur eine rein persönliche Geschmackssache und hat nichts mit der Qualität von Mint zu tun. Also die Live CD von Ubuntu ins Laufwerk und GParted starten. Die Partition für Fedora verkleinern und Kaffee trinken, denn die Verkleinerung der Partition ist ein langwieriger Prozess. Neustarten – ach, ich sollte vorher die Fedora-CD einlegen. Zu spät, Ubuntu startet schon – und ob ihr es glaubt oder nicht, ohne Fehlermeldung. Die Verkleinerung der Partition hat also schon gereicht, um den Fehler zu beheben. Gut gemacht, GParted. Jetzt habe ich also wieder ein fehlerloses Ubuntu, eine überprüfte HD und Platz für Fedora. Das ist recht erfreulich, denn am 22. Oktober kommt ja schon „Willi der Werwolf“, nein „wily werewolf„, also Ubuntu 15.10 heraus.

Weblinks:
GLib-CRITICAL: Source ID … was not found when attempting to remove it
Sublime Text on Ubuntu 14.04 – Keeps attempting to remove it
GLib-CRITICAL **: Source ID XXX was not found when attempting to remove it
Dateisystemcheck und
e2fsck(8) – Linux man page (falls jemand „man e2fsck“ auf der Konsole nicht eintippen kann.

Bild: Gparted-Logo von pixel-anarchy.de

Allgemein

EM-Quali: Schweden – Österreich

Schreibe einen Kommentar

emquali

Ich schreibe hier nichts zu den Details, denn ich bin keiner, der Millionen Team-Chefs von Österreich und das Spiel haben Sie ja hoffentlich nicht verpasst. Außerdem denke ich, dass sich sogar der Möchtegern, der von sich selbst am meisten überzeugt ist, allmählich lieber als Co-Trainer sieht und auf Marcel Koller vertraut.
Was sollte ich auch viel schreiben, wenn selbst dem Reporter schon nach wenigen Minuten die Superlativen ausgehen. Sie haben gerade einmal bis zum hyper-coolen Elfmeter in der neunten Minute gereicht.

Ich schreibe diesen Artikel deshalb, weil ich damit sagen will, was nur ich sagen kann. Ich habe mich mein Leben lang nicht für Fußball interessiert, bis zu dem Kopftor von Marc Janko. Ich weiß gar nicht mehr gegen wen wir da spielten, aber es war eines der ersten Qualifikationsspiele. Später brachte mich sein Fallrückzieher endgültig auf den Geschmack. Ich hebe hier Marc Janko hervor, weil er mir mit seinen herrlichen Aktionen als erster aufgefallen ist. Seither sehe ich jedes Spiel der Nationalelf und bin von jedem Spieler und dem Trainer begeistert. Ja, inzwischen kenne ich sogar schon die Regeln. 😉
Also nur ein kurzes, anerkennendes Dankeschön für die unglaublich guten Spiele. Insbesondere natürlich auch für das Spiel gestern, denn es war für mich sehr attraktiv und spannend. Es ist mir ein Rätsel, wie man so schnell und perfekt spielen kann. Es ist wirklich eine Freude solche Spiele zu sehen, sagt der ehemalige Anti-Fußballer.
Die haben mich sogar schon soweit gebracht, dass ich auch in der Bundesliga einen Favoriten habe. Als Rapid-Fan möchte ich mich aber noch nicht bezeichnen, sondern nur als Rapid-Sympathisant. Vom Nationalteam bin ich hingegen schon ein Fan. Ich glaube für die würde ich mich sogar in ein volles Stadion trauen, obwohl ich größere Ansammlungen von Menschen nach Möglichkeit immer meide.
Also dann, vielleicht sehen wir uns ja im Happel-Stadion wieder.

Info zum Spiel auf kleinezeitung.at ÖFB-Team nach 4:1-Sieg im Freudentaumel.

Bild ist ein Screenshot von der ORF Übertragung.

Allgemein

lighttpsd gegen Apache2 mit DAU

Ein Kommentar

Normal würde der Apache natürlich keine Vergleich scheuen müssen, obwohl der lighttpsd ja ganz gut sein mag, aber in meinem Fall hatte der Apache einfach keine Chance, was natürlich an mir lag.
Ja, wenn man irgendwann einen lighttpsd installiert und laufen hat, sollte man das nicht einfach vergessen. Nachdem ich den Apachen durch Konfigurationsfehler zum Absturz brachte, lies er sich nicht mehr starten. Nach langem hin und her beschloss ich, den Webserver neu zu installieren und entfernte zuerst die kaputte Installation mit purge, also auch den Konfigurationsdateien. Nach der Neuinstallation war ich sicher, dass ich neu anfangen konnte und startete den Apachen guter Dinge mit der Minimalkonfiguration. Doch zu meinem Erstaunen fand ich „(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80“ also „no listening sockets available“.
Das kann doch nicht sein, dachte ich mir, aber „netstat -tulpn | grep :80“ erklärte mir, dass da ein httpsd lauscht. ps aux bestätigt mir, dass ich den lighttpsd vergessen hatte. Ich benötigte ihn nicht mehr also habe ich ihn „removed“ und mich anschließend wieder einmal als DAU (dümmster anzunehmender user) bewiesen. Der Apache konnte für den Port 80 noch immer keinen socket anlegen und ich begann nach dem Problem zu googeln. Erst nach geraumer Zeit fand ich heraus, dass der lighttpsd trotz „remove“ noch immer lief. Naja, so hatte der Apache kein Chance, aber nach einem „killall lighttpsd“ war alles ruhig auf :80 und der Apache nahm endlich seinen Dienst auf.
Meine ganz unglaubliche Erkenntnis des Tages ist also: „es genügt nicht, wenn man zuerst feststellt, wer den Port blockiert, sondern man muss den Dienst auch stoppen“. Wow, jetzt bin ich wieder klüger geworden. 😉