Schlagwort-Archive: Xorg

Now fail already! Wenn der Browser über Umwege XOrg lahmlegt

Ugh. Schon wieder. Das Rattern in der Ecke hat meist eine recht konstante Ursache: Die CPU meines Laptops läuft auf 100% und sorgt für ordentliche Lüfterdrehzahlen. Gehen wir mal auf Ursachensuche:

Bei CPU-Last ist erster Anlaufpunkt natürlich top/htop. In meinem Fall aber leider nicht sehr Hilfreich: Xorg sei der Verursacher. Weites Feld. Aus meiner Erfahrung geht dann der Blick erst mal auf die laufenden Programme. Nicht selten hat sich auf einer geöffneten Webseite eine Flash-Werbung, ein HTML5-Video oder sonstige zappelnde Dinge mit Nervfaktor versteckt und bringen das Rendering in Gang. Leider konnte ich dieses mal nichts finden. Auch der interne Taskmanager von Google Chrome zeigt – anders als in solchen Fällen üblich – keine auffällig hohen Lasten. Um sicher zu gehen halte ich per SIGSTOP alle UI-Programme kurz an – keine Änderung. Es ist also mit hoher Wahrscheinlichkeit keine Grafikausgabe, welche die Probleme auslöst.

Zurück zum Start. Wir wissen, dass Xorg die Last bringt, allerdings vermutlich nicht im Grafikbereich. Schauen wir uns top nochmal genauer an. Die Browser sind noch in SIGSTOP und entsprechend verschwunden. Hinter XOrg macht sich nun dbus breit. Dbus? Kurze Lastspitzen OK, aber Dauerlast? Ein Blick mit dbus-monitor bringt eine Wall-of-log zum Vorschein:

…und das in Endlosschleife. Uhm, ja. mailto? Das sind üblicherweise Links in Webseiten oder Dokumenten um E-Mails zu versenden. Stimmt, ich hatte vor einigen Stunden auf einer Webseite einen Mail-Link angeklickt. Ohne Reaktion.

Offenbar hat sich die DE an eben diesem Maillink festgefressen. “Der angegebene Ort wird nicht unterstützt”. Kein Wunder, denn in den “Standardprogrammen” ist für E-Mails nichts hinterlegt. Anstatt das Ganze aber einfach als Fehlschlag einzuordnen und abzubrechen wird die Aktion in Endlossschleife ständig wiederholt. Da auch Xorg an Dbus hängt (und offenbar nicht sonderlich effizient auf dessen Events reagiert) geht auch dieser in die Knie. Da ich auf die Schnelle keine Möglichkeit fand das dbus-event rauszuwerfen musste ein Dummy-Mailprogramm hinhalten. Event geht rein, Returncode kommt, Dbus gibt Ruhe. Warum nicht gleich so?

BitBastelei #146 – SSH unter Linux

BitBastelei #146 - SSH unter Linux

(41 MB) 00:30:06

2015-04-26 12:00 🛈

Vom Verbinden bis zum Tunneln
Alle Angaben beziehen sich auf OpenSSH

Befehle:

Verbinden zum Rechner:
ssh evil.server

Verbinden zum Rechner mit Nutzerangabe
ssh anderernutzer@evil.server

Host-Keys anzeigen
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
(bzw. passender Key)

Host-Key aus “Adressbuch” löschen
ssh-keygen -R evil.server

Neues Schlüsselpaar erzeugen
ssh-keygen

Key auf Server kopieren
ssh-copy-id username@evil.server

Passwort eines Keys ändern
ssh-keygen -f ~/.ssh/id_rsa -p

Argumente
-p 1234 – Port 1234 statt Port 22 nutzen
-C – Kompression einschalten
-v – verbose – zusätzliche Ausgaben zur Fehlersuche

Lokale Weiterleitung
ssh -L 127.0.0.1:1234:192.168.0.2:80 evil.server
Lokale Verbindungen an Port 1234 werden über evil.server an 192.168.0.2 Port 80 weitergeleitet

Remote Weiterleitung
ssh -R 0.0.0.0:1235:127.0.0.1:80 evil.server
Verbindungen auf eine beliebige IP von evil.server auf Port 1235 werden an Port 80 des lokalen PCs weitergeleitet

SOCKS-Proxy
ssh -D 3128 evil.server
Es wird ein SOCKS-Proxy auf Port 3128 gestartet. Dieser kann z.B. mit Firefox genutzt werden

X11-Forwarding
ssh -XY evil.server
Nun können in der Sitzung grafische Programme gestartet werden. Die Anzeige erfolgt auf dem lokalen PC

Config-Files
Alle Argumente und weitere Optionen können global oder pro Ziel in den Konfigurationen hinterlegt werden. Die Benutzerkonfiguration ist unter ~/.ssh/config zu finden, die Systemweite üblicherweise unter /etc/ssh/ssh_config

Escape-Sequenz
In einer SSH-Sitzung kann man üblicherweise mit der Tilde-Taste (~) ein internes Menü aufrufen. Die Wichtigsten Befehle:
~? Hilfe anzeigen
~. SSH-Verbindung beenden (auch wenn Gegenseite nicht mehr reagiert)
~# Liste der Verbindungen (incl. Tunnel) anzeigen
~C Interne Konsole aufrufen – hier kann man nachträglich Tunnel (-L, -R, -D) aufbauen

Weitere Ideen:
– ssh-agent: Kennwörter für SSH-Keys mussen nur alle X Minuten eingegeben werden
– autossh: SSH-Verbindung bei Abbrüchen neu Aufbauen
– SSH mit Pipes: Pipes lassen sich über SSH auch an entfernte Rechner senden
2-Faktor-Anmeldung, z.B. mit Google Authenticator
Host-Keys in DNS hinterlegen

LUG-MYK

Arch Linux: Only console users are allowed to run the X server

Üblicherweise nutze ich an meinem Haupt-PC ein Multihead-Setup, also mehrere Monitore. Was zum Arbeiten praktisch ist bringt Spiele leider gerne aus dem Tritt. Um dem aus dem Weg zu gehen habe ich bisher über startx einen zweiten X-Server gestartet – direkt aus der GUI, somit war auch Pulseaudio & Co immer direkt nutzbar. Seit einem der letzten Updates, vermutlich die neue Rootless-Funktion von xorg 1.16, erscheint nur noch die Meldung “Only console users are allowed to run the X server”.

In einem Post auf Github wird empfohlen eine Datei /etc/X11/Xwrapper.config mit dem Text “allowed_users=anybody” zu erzeugen. Generell ein Fortschritt, nun bricht jedoch beim Start der propritäre NVidia-Treiber wie folgt zusammen:

(EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed
(EE) NVIDIA(GPU-0): Failed to allocate EVO core DMA push buffer
(EE) NVIDIA(0): Failing initialization of X screen 0

Leider konnte ich den genauen Auslöser nicht finden – die Rechte sinds nicht, setuid/setgid oder start als root zeigt keine Änderung. Auch ein Wechsel auf die freien Nouveau-Treiber zeigt keine Änderung, hier kann in der zweiten Sitzung kein DRI inizialisiert werden. Glücklicherweise hat der freie Treiber deutlich weniger Rendering-Bugs – nicht nur, dass Chromium endlich wieder nutzbar ist – auch Spiele laufen nun im Multi-Monitor-Modus. Zwar erscheint das Bild immer auf den linken Monitor, aber mit einem VGA-Umschalter als Hardware-Workarround kann ich mir da behelfen.

Arch Linux: Mehrere X-Server, Systemd und VT-Switch

Die Migration auf Systemd hat noch immer ihre Nebenwirkungen auf meinem System: Ich verwende hauptsächlich ein Multimonitor-Setup auf meinem Rechner. Leider unterstützen nicht alle Anwendungen ein solches Konstrukt fehlerfrei, daher nutze ich von Zeit zu Zeit einen zweiten XOrg mit nur einem Monitor um die Software zu betreiben. Um diesen zu starten nutzte ich bisher den Befehl startx -- :1 -layout LayoutSingle. Über das übliche VT-Switch konnte ich ggf. zwischen den Serven wechseln, die Multimonitor-Lösung befand sich auf vt7 (Ctrl-Alt-F7) und der zweite Server mit nur einem Monitor auf vt8 (Ctrl-Alt-F8).

Nach der Migration auf Systemd war damit Schluss: Zwar startete der zweite X-Server normal und ich konnte ihn benutzen, habe ich ihn aber einmal auf eine andere Konsole verlassen gab es keine Möglichkeit mehr auf den Bildschirm zurück zu kommen. Zum Glück ist die Lösung recht einfach und offensichtlich (wenn man sie erst mal gefunden hat) – der Befehl zum Starten heißt nun startx -- :1 -layout LayoutSingle vt8