Leap 42.2 Eingefrorenes System bei Multimedia abreiten

Hinweis: In dem Thema Leap 42.2 Eingefrorenes System bei Multimedia abreiten gibt es 37 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hallo Leute,



    bitte verzeiht die lange Zeit in der ich nicht geantwortet habe.



    Alero: Das Anlegen eines neuen Users hilft nicht.



    JeyF123: Ich kann den top-Befehl nur einsetzen, wenn das System noch reagiert. Wenn es eingefroren ist, dann habe keinen Zugriff mehr darauf.



    mofe: Bei dem Laptop wird eine Intel-Grafikkarte verwendet.



    Bei meinem Vergleich mit Tumbleweed bzw. meinen anderen SuSe-Systemen sind mir diverse Punkte aufgefallen, die sich unterscheiden.
    Zum einen wird das Touchpad nicht richtig erkannt, das System wirkt oft als träge (bei der Benutzung von LibreOffice, Thunderbird & co) und so weiter.



    Für mich wirkt es so, als ob ein Treiber/Kernel-Problem vorliegt.
    Ich kontrolliere mal die Unterstützung der verbauten Komponenten und schaue mir noch mal die Journaleinträge auf Fehler an.

    Für den Inhalt des Beitrages 108147 haftet ausdrücklich der jeweilige Autor: -kubus-

  • hm, würde es Sinn machen

    Code
    top


    in eine Datei zu protokollieren? Hatten wir

    Code
    journal -e


    bereits? Läuft die Temperatur hoch? (sensors)
    Gab es nicht ein Shortcut um die Desktopeffekte aus und einzuschalten?
    Ok, das ist vllt. ein wenig viel sinnlose Streuung.


    PS.. meinte

    Code
    journalctl -e

    Für den Inhalt des Beitrages 108149 haftet ausdrücklich der jeweilige Autor: JeyF123

  • Verwende top im Batchmode.


    Sowas, wie
    top -b -d 1 | tee somefile (-batchmode -delay 1 Sekunde, also jede Sekunde ein Prozessscan)
    bei Systemstart eingeben.


    Kann ziemlich fettes File werden.
    Wenn wenig Platz auf der Platte, dann sowas:


  • Das sind zwei prinzipiell verschiedene Dinge.
    Und es geschehen wundersame Dinge im Hintergrund.


    Die Pipe, das | Zeichen, verkettet zwei Befehle.
    Unter Unix/Linux Betriebssystemen gilt der Grundsatz:
    Everything is a file


    So ist ein Terminal eine Datei, eine Gerätedatei. Siehe ls /dev/tty*
    Eine Partition ist eine Datei. Siehe ls -R /dev/disk/*


    Und jeder Prozess hat vom Start weg drei "Gerätedateien".
    Die STDOUT, die STanDardOUTput Datei.
    Die STDIN, die STanDardINput Datei.
    Und noch eine STDERR, die STanDardERRor Datei.


    Der Linuxkernel kennt aber nicht solche Begriffe, sondern nur Zahlen.
    Die STDIN Datei ist dabei die 0.
    STDOUT die 1.
    STDERR die 2.


    Wenn du also eine Konsole (die eigentlich ein xterm startet), dann sind dem darin laufenden Bashprozess von Anfang an diese drei Dateinummern, sogenannten FileDescriptoren, zugeordnet.
    Ein ls /proc/$$/fdinfo zeigt das. ( /proc ist eine Pseudodateisystem. Es macht die internen Datenstrukturen des Kernels sichtbar. Und vor allem sehr leicht lesbar. Falls man lesen darf. Schreiben geht auch, falls man darf.
    Und $$ wird von der Bash expandiert. Die Variable, die die eigene Pid (==ProcessIDentificationnumber) darstellt, heißt $ und das vorangehende $ triggert die Expansion. Der Befehl, der wirklich ausgeführt wird, ist also ls /proc/<eigenePid>/fdinfo )


    Und wenn der User nichts verbogen hat, dann zeigt eben der Filedescriptor 1, also STDOUT auf die Gerätedatei "Bildschirm" und der Krempel, der dorthin geschrieben wird, wird sichtbar. STDIN ist (indirekt) mit der Gerätedatei des Keyboards verbunden, und STDERR, wo normalerweise Warnungen, Fehlermeldungen ausgegeben werden, ist ebenso auf dem Bildschirm, also ebenso mit der Gerätedatei "Bildschirm" verbunden.


    Wenn man nun eine Eingabeumlenkung < oder eine Ausgabeumlenkung > vornimmt, so werden einfach von der Bash die Dateidescriptoren umgebogen.
    Das lässt sich leicht demonstrieren, wenn man in einem solchen Terminal folgendes eingibt:
    ls /proc/$$/fdinfo zur Anzeige, was wir hier gerade für FDs (==FileDescriptor) haben.
    exec 8>halligalli Wir definieren Dateidescriptor Nummer 8 als eine Datei im aktuellen Verzeichnis. Das exec ist ein übler Befehl, der mehr kann, aber gut verstanden sein will, was aber diesen Rahmen jetzt wirklich sprengen würde. Daumenregel: NUR für solche Umleitungen verwenden, oder Finger weg!
    Und siehe da: ls /proc/$$/fdinfo Es gibt jetzt den Filedescriptor Nummer 8 verbunden mit einer Datei.
    ls -l halligalli und die Datei gibt es auch schon. Mit Zero Bytes.
    Wir schreiben was rein.
    echo "Na sowas" >&8 Das meint echo "Na sowas" nicht auf den Bildschirm, sondern > in die Datei, die unter der Adresse & des Dateidescriptors Nummer8 erreichbar ist, also die Datei "halligalli".
    cat halligalli jou. geht.
    exec >&8- "löscht" den Dateidescriptor wieder. Aber nicht die Datei. "Schliessen" wäre der bessere Ausdruck, wenn auch tatsächlich diese Operation ganz offensichtlich löscht. (Joke. sieht halt so aus....)
    ls /proc/$$/fdinfo Hat wohl jemand unsere 8 "gelöscht".... Wir erinnern uns: /proc ist ein Pseudodateisystem!


    Damit wären nun Eingabeumlenkung < und Ausgabeumlenkung > erklärt.


    Bei dem Pipen | passiert das Gleiche. Nur ein wenig mehr. Man nennt die Pipe auch Verkettungsoperator.
    Es werden damit zwei Befehle verbunden. Die Ausgabe des ersten Befehls wird zur Eingabe des zweiten Befehls.
    Der STDOUT (Filedescriptor Nummer 1) des ersten Befehls zeigt auf den STDIN (Filedescriptor Nummer 0) des zweiten Befehls.
    Voila: Der zweite Befehl empfängt die Ausgabedaten des ersten Befehls zur Weiterverarbeitung.
    Schlicht, einfach. Linux. Everything is a file.


    Aber ganz soo einfach ist die Sache dann doch nicht.
    Damit das funktionieren kann, muss die Bash ja beide Kommandos so einrichten, dass die auch mit den korrekten Umleitungen starten.
    Einfach aufrufen, wie wir es normalerweise machen, fällt also aus, wegen is nich.
    Wenn die Bash also nach dem Parsen unserer Eingabezeile geschnallt hat, dass sie verschiedene Kommandos zu verbinden hat, also pro Pipe- Zeichen bei zwei Prozessen Ein- und Ausgabe umlenken muss, so ruft sie eine Subshell. Also ein neuer Prozess, der jetzt nicht interaktiv, eine ganze Befehlskette ausführt.
    Dazu erzeugt sie noch Buffer, damit die Daten zwischen den Befehlen zwischengespeichert werden können. (Selbstverständlich kann man das Buffern auch unterbinden.)
    Das hat enorme Konsequenzen. Wenn wir in einem Script (oder interaktive) eine solche Befehlskette mit Pipe- Zeichen stehen haben, so kann zwar jede Subshell alle Variablen lesen, weil die Bash das komplette Environment mit an alle Subshells übergibt, aber jede Änderung an solchen Variablen ist nach dem Ende dieser Subshell einfach weg.
    Es ist prinzipiell nicht möglich das Environment (wo alle Variablen irgenwie hausen) des Vaterprozesses zu ändern.


    Und der Befehl tee tut genau das, was beim Klempner halt ein T- Stück macht.
    Genau daher kommt der Name.
    Es ist ein T- Stück für die Daten.
    Die Ausgabe des ersten Befehls wird beim T-Stück abgeleitet in die beim tee Befehl angegebene Datei UND fließt trotzdem weiter auf den Bildschirm.
    Oder, wie wir Linuxkenner jetzt formulieren würden: Der Dateidescriptor Nummer 1 wird dupliziert. Halt auf irgendeinen zweiten, der mit einer Datei verbunden ist, die beim tee Befehl angegeben ist.


    Es gibt kein "besser" oder "schlechter".
    Es gibt nur passender, oder weniger sinnvoll.
    Und alle möglichen andere Dinge. Aber kein "besser" und kein "schlechter".
    Auch ein Linuxgrundsatz: Tue nur ein kleines Ding, das aber richtig gut, möglichst vollständig und universell.
    Ein riesiger Setzkasten an sehr mächtigen Befehlen, die man nach Belieben zusammenstöpselt um völlig irre leistungsfähige Befehle zu schaffen.

  • @Berichtigung
    Vielen Dank. Was sagt uns die letzte Zahl der Ausgabe vonls /proc/$$/fdinfo (255)?

    be tolerant - not ignorant
    Alle Hunde sind schwarz.
    Es gibt einen Hund der nicht weiß ist.

    Für den Inhalt des Beitrages 108162 haftet ausdrücklich der jeweilige Autor: Boreas

  • @Berichtigung
    Vielen Dank. Was sagt uns die letzte Zahl der Ausgabe vonls /proc/$$/fdinfo (255)?

    Nichts.


    Also bevor ich jetzt zugebe, dass ich das schlicht vergessen habe und nicht wiederfinde,
    lüge ich lieber. OK, ich phantasiere ein wenig.
    Klingt besser, oder?


    Auch keine gute Idee.
    Lass es und schnell rausfinden.


    Das geniale an dem Paradigma everything is a file ist ja, dass man es ganz schlicht ganz genau so lesen und schreiben kann, wie jede andere schlichte Datei auch. Falls man darf.
    Wir brauchen nicht irgendwelche vogelwilden Spezialprogramme, um Dateien zu schreiben oder Infos aus dem Kernel zu lutschen.
    Es liegt (fast) alles offen.
    Wenn wir es verstehen würden.


    Was ist denn das für ein Ding?
    ls -l /proc/$$/fdinfo/255 ergibt irgendwie so eine Zeile
    -r-------- 1 looser loosers 0 10. Mai 15:21 255
    Aha, weil der Bezeichner, der ganz am Anfang als erstes Zeichen vor den eigentlichen Dateirechten steht, ein Bindestrich ist, handelt es sich also um eine ordinäre Datei.
    cat /proc/$$/fdinfo/255 Die gucken wir uns einfach mit cat an und erhalten irgendwie sowas:
    pos: 0
    flags: 02100002
    mnt_id: 22
    Das pos: meint den Dateizeiger, also die Position in der Datei, wo wir gerade lesen. Wer schon mal in irgendeiner Sprache ein Progrämmchen verbrochen hat, kennt das Konzept des open_read, seek, rewind Mechanismus. Das System merkt sich beim Lesen (oder Schreiben) die Position. Jeder Schreib- und Lesevorgang auf diese Datei findet exakt an dieser Stelle statt.Die flags erklären sich von selbst. Sie repräsentieren die tatsächlichen Dateirechte.Und mnt_id: is ja auch sonnenklar. Eben die MOUNT_IDentifikation.Hä? Wos is na des?
    OK. Wir lesen es einfach, is ja schließlich everything a file.
    grep -E '^22' /proc/$$/mountinfo was zu sowas führt:
    22 19 0:14 / /dev/pts rw,nosuid,noexec,relatime shared:5 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
    Das liest sich schon fast, wie ein Mountbefehl. Nur dass es diesmal offensichtlich um ein /dev Gerät geht, das pts heißt (pts == PseudoTerminalSlave).
    Alles klar.
    Echt?
    Na ja.


    Wir gucken mal lieber, was dort tatsächlich ist, weil ja schliesslich everything a file is.
    ls -l /dev/pts Au Backe. Schon wieder sehen wir so komisches Zeuchs:
    crw------- 1 looser tty 136, 0 10. Mai 15:11 [b]0[/b] 
    crw------- 1 looser tty 136, 1 10. Mai 15:11 [b]1[/b]
    crw------- 1 looser tty 136, 2 10. Mai 16:55 [b]2[/b] 
    c--------- 1 root root 5, 2 10. Mai 15:07 [b]ptmx[/b]
    Wie haben es hier aber nur mit CharacterDevices zu tun, weil das erste Zeichen in den Rechten eben ein characterdevice bezeichnet.
    Solche Geräte werden zeichenweise gelesen oder geschrieben. Im Gegensatz zu Blockdevices, wo es sich immer um Blöcke von Bytes handelt, die verschoben werden.
    So ziemlich alle Geräte sind Characterdevices -egal ob Webcam, Netzwerkstream oder Terminalgebabbel.
    Und wirklich nur die Speichermedien, wie Festplatten und dergleichen sind Blockdevices.


    Auffällig ist außerdem, dass das Gerät ptmx (==PseudoTerminalMultipleXer) root alleine gehört, die anderen, deren Sinn uns ja schon klar ist, aber dem looser gehören.


    Was hat es damit auf sich?
    Dazu machen wir Computerarchäologen einen kleinen Ausflug in die Steinzeit.
    Lange vor der Zivilisation wurden die digitalen Rauchzeichen über die normale uralte analoge Telephonverbindung übertragen. In der Tat rief man mit einem normalen Telephon ein anderes altes analoges Telephon an. Auf beiden Seiten stand aber kein Mensch am Hörer, sondern ein Analog/Digitalwandler. Ein schlichtes Gerät, das Töne in Klopfzeichen übersetzte. Analog zu Digital halt.
    Und das waren damals die gängigen Netzwerkverbindungen. Besonders teure gab es natürlich auch. Große Firmen mieteten sogar Standleitungen. Die einzige Gemeinsamkeit, die wir heute zu damals haben, ist, dass es heute, wie damals keine günstige Verbindung gab. Das scheint mir aber nur eine Konstante für Deutschland zu sein. Es gibt viele Entwicklungsländer, die ihren Bürgern kostenlos Glasfaseranschlüsse in die Wohnung legen. Versuch das mal hier bei uns. (Was kostet ne Couch zur Untermiete bei dir?)


    Es begann ein Wettrüsten. Und unzählige, klobige Kisten entstanden, die einen Telephonanschluss hatten, einen Bildschirm und eine Tastatur. Eben ein Terminal.
    Jedenfalls sonnte sich die Speerspitze des technologischen Fortschritts in Lügeting®™gesabbel, dass man das beste Terminal habe, weil es statt grün auf schwarz das sicherlich ergonomisch weltallerbeste bernsteinfarbene Terminal bieten könne. Ja, entgegneten die Gegner, aber unser Terminal kann sogar fett am Bildschirm darstellen. Und wir können nicht nur fett, sondern sogar blinkend und unterstrichen, weshalb sowohl bernstein, wie auch fett ausgebende Terminals ganz sicher veralteter Müll wären.
    Der Krampf der Firmen tobte.
    Mit dem Resultat, dass ein Wildwuchs an Terminalsprachen entstand. Jedes Terminal musste natürlich mit den entsprechenden streng geheim und firmeninternen Steuercodes bedient werden, um schlicht auf blinkende Darstellung umzustellen.
    Die Rootgötter im Rechenzentrumsolymp wurden sauer. Richtig sauer. Deren einziger Innovationsmotor ist ja Faulheit. Das Ding soll alleine laufen, und zwar richtig. Für jedes neue dämliche Terminal wieder für beide Seiten einen weiteren Treiber schreiben? Geht's noch?


    Wir merken uns: Konkurrenz belebt nicht das Geschäft, es hält die Leute in sinnloser Sklavenarbeit, schafft überflüssige, nicht funktionierende Produkte und der schlechtest mögliche Kompromist®™ wir Standard.


    Man erfand das Konzept des Pseudoterminals. Die Rootgötter würden nie wieder solche dämlichen Terminanpassungen machen, und die Hersteller müssten schlicht diese vereinheitlichte Terminalsprache verstehen können und auf ihrem Terminal einfach umsetzen. Damit wurde auch das ständige Übertragen von Steuersequenzen drastisch reduziert.
    Auf dem Großrechner, bei dem all die digitalisierten Telephongespräche gebündelt wurden, musste keine Zeit mehr damit verbraten werden die Daten für das jeweilig anrufende Terminal passend zu codieren, stattdessen reichten ein paar Grundtypen, die man leicht auswählten konnte. Das war die Geburt von man terminfo und man termcap.
    (Dass das ein weites Gebiet ist zeigt uns auch man term<tab><tab>)


    Und das Lügeting®™ kaschierte die eigenen Sünden, mit der Fortschrittsposaune, wie schnell man auf einmal wäre, sogar die nigelnagelneue Terminalsprache würde man auch selbstverständlich verstehen. Die Kisten waren billiger geworden, weil weniger Schaltungen nötig waren, der Entwicklungsaufwand ebenfalls drastisch minimiert, weshalb die Preise dafür natürlich drastisch stiegen. Wie in der richtigen Wirtschaft auch.


    Damit wären nun die Pseudoterminals erklärt. Heute braucht man den ganzen Müll nicht mehr. Es wird alles nur noch emuliert. Selbst das kleinste Smartphone hat heute unglaublich viel mehr Speicher, als die damaligen Rechenzentren. Aber der Müll lebt noch weiter und graphische Darstellungen in irgendwelchen Terminals bringen alle Computereleven noch heute richtig in's Schwitzen. Funktioniert heute noch nicht zuverlässig und erst recht nicht systemübergreifend.


    Wir merken uns weiter, dass die Bibel und ich immer recht haben: "Und es schleppen sich die Sünden der Väter als üble Krankheit von Geschlecht zu Geschlechte fort."
    Auf uns hört leider immer keiner.


    Bleibt noch der Multiplexer selber. Das ist lediglich eine Art Schalter, der zwischen verschiedenen -heute rein logischen Verarbeitungsketten, früher wirklich zwischen verschiedenen Telephonleitungen- hin- und herschaltet. Man muss für den gleichen Käse ja nicht gleich eine eigene Küche bauen und ein eigenes Käsemesser kaufen.


    Da dieser veraltete Verarbeitungsmüll aber schon aus Kompatabilitätsgründen fortleben muss, werden noch heute alle Terminalausgaben über diesen Gerätewirrwarr abgewickelt.
    Die einzige tatsächliche heute noch sinnvolle Funkion ist, dass die Pseudoterminals in die Daten, die über den Multiplexer mit der richtigen "Leitung" verbunden sind, Steuersequenzen einstreut (hatte ich schon mal erwähnt, dass everything a file ist?).
    Das läuft für den Looser aber völlig transparent.
    Falls man nicht selber dranrumfummeln will.
    Der wichtigste Befehl, den man blink tippen können sollte, lautet dafür reset<enter>
    Egal wie sehr man seine Terminalausgabe völlig unlesbar und wirr gekriegt hat, mit reset dauert es kurz, das Pseudoterminal wird komplett neu initialisiert und die Welt ist wieder schön lesbar.


    That's all.


    Es ergeht folterndes Urteil:
    Da der Frager mit einer kleinen harmlosen Frage nach einer großen Zahl einen fundiert langen Käse evozierte,
    - wie einfach, herrlich und faul wäre die Welt gewesen, hätten wir uns auf die Descriptoren 0, 1 und 2 beschränkt-
    ist mir ab Glasfaseranschluss die Couch mietfrei für drei Jahre zu überlassen.
    Samt professioneller italienischer Kaffeemaschine und bayerischer Zapfanlage,
    und die jeweiligen Ausgabestellen von Tasse und Maßkrug in Armlänge von Mitte Couch erreichbar. Eh klar.


    Amen.

  • @Berichtigung
    Vielen Dank. Ich versuch' das mal zu verarbeiten - geht sicherlich nicht so schnell wie wir in Deutschland hier ein schnelles Netz bekommen. Macht nix bin ja jung.

    be tolerant - not ignorant
    Alle Hunde sind schwarz.
    Es gibt einen Hund der nicht weiß ist.

    Für den Inhalt des Beitrages 108181 haftet ausdrücklich der jeweilige Autor: Boreas