Siduction Forum
Siduction Forum => Software - Support => Topic started by: michaa7 on 2021/12/07, 16:29:55
-
$ cat /proc/sys/kernel/sysrq
1
Sysrequest ist wohl enabled. Aber nichts passiert bei "Alt - S-ABF - T" oder "Alt - S-ABF - D". Muss das alles erst manuell eingerichtet werden? Falls ja, gibt es eine empfohlene config?
-
Also bei mir funktioniert das wunderbar.
Ist das vielleicht ein Laptop? Da kann es sein, dass man noch die Fn-Taste braucht, manchmal auch AltGr anstatt Alt.
Hier https://wiki.ubuntuusers.de/Magic_SysRQ/ (https://wiki.ubuntuusers.de/Magic_SysRQ/) sind ein paar Möglichkeiten aufgeführt.
Ach ja nur um das offensichtliche auszuschließen, dir ist schon klar, dass Alt+S-Abf+t und Alt+S-Abf+d nur im Textmodus (aka. tty) funktionieren. anscheinend in den Kernel-Ringpuffer (also nach dmesg) printen.
-
Hi, nein kein Laptop, sondern ordinärer Desktop.
...
Ach ja nur um das offensichtliche auszuschließen, dir ist schon klar, dass Alt+S-Abf+t und Alt+S-Abf+d nur im Textmodus (aka. tty) funktionieren. anscheinend in den Kernel-Ringpuffer (also nach dmesg) printen.
Nein, das wußte ich nicht.
Das ist allerdings Grund für bisherige Missverständnisse. Danke für diesen Hinweis.
Ich bin auf der Suche danach wie ich bei einem abgesoffenen Rechner (stundenlang idle bzw im Background über ssh moc (Music over commandline) eine jukebox steuernd), der nach einem mausbewegung nicht wieder hochkommt sondern laut I/O Leuchte mit irgendwas so beschäftigt ist dass er auch nach einer Viertelstunde die Graphik gerade einmal halb, d.h. unvollständig darstellt irgendwie an brauchbare info zu kommen oder an eine Oberfläche die mich dinge abschießen läßt (nee, htop ist ja nicht erreichbar, nichteinmal an eine Konsole (Strg-ALT-F(2-6)) komme ich. Der Rechner ließ sich nur per Hardresett abschießen.
Ist über sysrq irgendetwas hilfreiches erreichbar? dmesg ist dazu ja ehr ...sinnlos.
EDIT:
Mir ist zudem nicht klar warum heute nachmittag, als ich auf diesem Rechner *testweise* Alt+S-Abf+t und Alt+S noch *nicht* ausgeführt hatte es zu folgender Ausgabe kam:
$ cat /proc/sys/kernel/sysrq
1
Jetzt, nachdem ich Alt+S-Abf+t und Alt+S genutzt habe steht dort:
$ cat /proc/sys/kernel/sysrq
438
-
Hm also ich bin da eher so der Typ der sich im Nachhinein die Logs ansieht.
Allerdings kannst du/man mit SysRq+k die gesamte GUI killen (genauer gesagt alles auf dem momentanen Terminal) oder du könntest mit SysRq+f einfach mal den OOM-Killer aktivieren und schauen ob das dein Problem behebt.
Das ist natürlich auf die Dauer keine Lösung des Problems, aber vielleicht wird das System dadurch wieder so benutzbar, dass man an verwertbare Logs kommt und nicht gleich auf REISUB oder einen hard reset ausweichen muss.
Das mit den veränderten Werten in /proc/sys/kernel/sysrq kann ich auch nicht beantworten, da weiß ich einfach nicht genug drüber.
-
Hm also ich bin da eher so der Typ der sich im Nachhinein die Logs ansieht.
Welche? Außer dmesg gibt es ja nichts mehr ?
Wenn also demnächst der Rechner wiedermal abgesoffen ist weil er nichts tat außer per ssh moc auf der jukebox zu steueren (was so gut wie gar keine ressourcen benötigt) und vielleicht der Browser (vivaldi) noch mit zwei, drei Tabs in der Taskbar lag ohne eine wirklich ressourcenfressende Verbindung und er dann ***nach Stunden*** nach einer Mausbewegung die Graphik nicht hochkommt sondern die I/O Leuchte des Rechners ins Dauerleuchten übergeht, und nach eine Viertelstunde bestenfalls Teile der Graphik wieder sichtbar, aber nicht bedienbar sind, und ich dann ein ALT - Sys-rq < R E I S U B > ausgeführt habe, welche Logs würdest du suchen? Wo finde ich irgendetwas was den I/O Sturm betrifft?
-
Welche? Außer dmesg gibt es ja nichts mehr ?
Fehlt's da bissel an Grundlagen?
journalctl -b -1
Und schon sieht man, was beim vorherigen Boot so passiert ist.
Voraussetzung ist latürnich ein persistentes Journal.