Was, wenn selbst strg alt f1 nicht mehr funktioniert?

[tsojtsoj]

Ich hab zurzeit öfter das Problem, das eine ziemliche neue Debian-Testing Installation mit cinnamon sich aufhängt sodass nur noch brutales stromweg hilft.
Wenn diese Situationi auftritt (Wenn der Desktop nichts mehr macht), drücke ich normalerweise strg+alt+F1 und warte min. 10 Minuten.
Das Problem selbst könnte irgendwas mit dem VLC-Media Player zu tun haben, bin mir da aber nicht sicher.
Was wäre das beste, was ich tun könnte um in solchen Situation den Computer sicher runterzufahren, vor allem so, dass möglichts keine Daten verlorengehen. Ich dachte es gibt noch so eine Notfallkombination (strg+alt+entf 7x schenll drücken oder so?) aber alles was ich in die richtung probiert habe scheint auch nicht zu funktionieren.

[MSfree]

Das Problem selbst könnte irgendwas mit dem VLC-Media Player zu tun haben,

Das glaube ich nicht. Wenn, dann hat der X-Server ein Problem. Hast du die nötigen Treiber und Firmwares installeirt?

Was wäre das beste, was ich tun könnte um in solchen Situation den Computer sicher runterzufahren

1. versuche, dich von einem anderen Rechner per SSH einzuloggen und reboote den Rechner

2. systemctl enable ctrl-alt-del.target sollte den bekannten Affengriff ermöglichen, der dann zu einem Reboot führen sollte.

3. wenn weder 1. noch 2. erfolgreich sind, hängt die Kiste so gründlich, daß ohnehin nur noch der Resettaster oder trennen von der Stromversorgung helfen.

[KBDCALLS]

1. versuche, dich von einem anderen Rechner per SSH einzuloggen und reboote den Rechner

2. systemctl enable ctrl-alt-del.target sollte den bekannten Affengriff ermöglichen, der dann zu einem Reboot führen sollte.

3. wenn weder 1. noch 2. erfolgreich sind, hängt die Kiste so gründlich, daß ohnehin nur noch der Resettaster oder trennen von der Stromversorgung helfen.

Ne vierte Möglichkeit die Magic Sysrq Keys

• https://de.wikipedia.org/wiki/Magische_S-Abf-Taste

[breakthewall]

Kann das sein das keine Swap erstellt hast? Denn ich kenne dieses Szenario nur in dieser Form, dass irgendein Programm plötzlich den RAM auffrisst, und somit alles andere darunter leidet. Dann passiert genau das, dass unter anderem der Desktop Minuten lang nicht reagiert. Mit einer Swap passiert das erst garnicht, womit einen entsprechenden Puffer hast zum Auslagern. Da könntest jederzeit eingreifen, wenn etwas ausartet. Aber auch generell können Systemrichtlinien definiert werden, um systemweite Limits durchzusetzen was Programme an RAM verbrauchen dürfen. Bin gerade am überlegen welches tty standardmäßig von Cinnamon genutzt wird. Hast überhaupt alle durchprobiert, also die sieben verbleibenden? Wenn ausgerechnet das tty der Login-Shell via Tastenkombination ausgewählt hast, dann wirst den aktuell eingefrorenen Desktop auch nicht verlassen.

[rendegast]

Du kannst ein Skript an den zBsp. powerbutton hängen.
Verbunden mit diversen Aktionen für zBsp. 1mal drücken 2mal drücken usw.
Da das von acpid überwacht wird (gegebenenfalls mit systemds Aktionen abgleichen)
ist es unabhängig von X resp. einer mit X abgestürzten Tastatur.

Eine /etc/acpi/powerbtn.sh ruft auf /etc/acpi/powerbtn.d/powerbtn_locks:

Code: Alles auswählen

#!/bin/sh
#Sun Oct 25 16:37:35 CET 2009

# Neuorganisation, um mit dem powerbutton mehr Moeglichkeiten zu haben.

# Mehrstufiges Verfahren, mit Lock-Dateien.
# /var/run/ statt /tmp/, da dort kein sticky-Bit/write-all
PWD_DIR=/etc/acpi/powerbtn.d
LOCK_DIR=/var/run
. /etc/acpi/FUNCTIONS.sh

LOCK0=$LOCK_DIR/acpi_LOCK0
LOCK1=$LOCK_DIR/acpi_LOCK1
LOCK2=$LOCK_DIR/acpi_LOCK2
LOCK3=$LOCK_DIR/acpi_LOCK3
LOCK4=$LOCK_DIR/acpi_LOCK4
LOCK5=$LOCK_DIR/acpi_LOCK5
LOCK6=$LOCK_DIR/acpi_LOCK6
LOCK7=$LOCK_DIR/acpi_LOCK7
LOCK_WAIT=$LOCK_DIR/acpi_LOCK_WAIT

[ -e $LOCK_WAIT ] && { rm $LOCK_WAIT; exit 0; }
[ -e $LOCK7 ] && exit 0
[ -e $LOCK6 ] && > $LOCK7
[ -e $LOCK5 ] && > $LOCK6
[ -e $LOCK4 ] && > $LOCK5
[ -e $LOCK3 ] && > $LOCK4
[ -e $LOCK2 ] && > $LOCK3
[ -e $LOCK1 ] && > $LOCK2
[ -e $LOCK0 ] && > $LOCK1

[ -e $LOCK0 ] && exit 0
> $LOCK0

# Listing:
for i in $PWD_DIR/ACTION_LOCK*; do
    run-parts --test $i
done | TEE

# Entscheide die Aktion
# Nochmal ein Frage-Zyklus zur Bestaetigung
# in Untershell, da sonst 'LAST_LOCK' sofort ausgewertet wuerde
{ sleep 5; beep -f 2500;
    LAST_LOCK=`ls -1 $LOCK_DIR/acpi_LOCK* | tail -n1 | sed 's@/var/run/acpi_@@'` && > $LOCK_WAIT;
    echo "
    LAST_LOCK: $LAST_LOCK
    RUN-PARTS:
`run-parts --test $PWD_DIR/ACTION_$LAST_LOCK*`

    Zur Durchfuehrung der Aktion nochmal den startbutton
" | TEE;
    sleep 5; beep;
    [ -e $LOCK_WAIT ] || run-parts --report $PWD_DIR/ACTION_$LAST_LOCK* | TEE;

    rm $LOCK_DIR/acpi_LOCK* && echo "LOCKS geloescht, Aktion beendet" | TEE;
} &

exit 0

Über die Verzeichnisse
/etc/acpi/powerbtn.d/ACTION_LOCK0.../
bis
/etc/acpi/powerbtn.d/ACTION_LOCK6.../
kann ich dann diverse Aktionen zuweisen, zBsp. halt, reboot, X killen, ssh start/stop, chvt usw.
Im Fall des Falles kann mensch sich an die Belegung/Bedienung nicht mehr erinnern,
daher besser einen Merkzettel an den Rechner kleben.

Als Schmankerl werde ich über die in /etc/acpi/FUNCTIONS.sh definierte

Code: Alles auswählen

TEE () {
    tee /dev/tty1 | \
    tee /dev/tty2 | \
    tee /dev/tty3 | \
    tee /dev/tty4 | \
    tee /dev/tty5 | \
    tee /dev/tty6
}

auf allen Konsolen über die Aktion informiert.

[DeletedUserReAsG]

Ne vierte Möglichkeit die Magic Sysrq Keys

• https://de.wikipedia.org/wiki/Magische_S-Abf-Taste

Die muss man unter Umständen noch aktivieren. Also einfach mal testen, wenn die Kiste noch reagiert, und ins Log schauen, wenn’s nicht tut.

[pangu]

Die muss man unter Umständen noch aktivieren. [...]

? was genau meinst du mit "aktivieren"? mir hat REISUB einmal ziemlich den A**** gerettet und ein andres Mal konnte ich bei einem Problemfall syncen und mounten. Aber ich höre das zum ersten Mal, dass man das "irgendwo" aktivieren müsste. Oder meintest du jetzt lediglich irgendwelche Spezialtasten/Fn-Keys bei Notebooks ?

[DeletedUserReAsG]

was genau meinst du mit "aktivieren"?

Ich meine, dass bestimmte oder alle SysRq unter Umständen in der /proc/sys/kernel/sysrq deaktiviert sein können, und man daher vorher nachschauen sollte, ob der gewünschte SysRq auch tut. Hatte da mal so ’ne Situation, in der ich den OOM-Killer gebraucht hätte und nicht anfordern konnte, weil dieser Request unterbunden war.

[KBDCALLS]

Was mich wundert das Debian einen ziemlich kruden Wert für kernel.sysrq als Voreinstellung hat. Mit ALT Druck R E schießt man den X Server ab. REISUB ergibt einen Reboot. Den eingestellten Wert kann man abfragen.

• Code: Alles auswählen

  sysctl kernel.sysrq

Einstellen kann man den in

• Code: Alles auswählen

  /etc/sysctl.conf

[tobo]

Was mich wundert das Debian einen ziemlich kruden Wert für kernel.sysrq als Voreinstellung hat.

Gibt's noch was anderes außer 0 und 1?

[DeletedUserReAsG]

Ja: https://www.mjmwired.net/kernel/Documentation/sysrq.txt

[KBDCALLS]

438 mit Lenny i386. Sid und AMD64 dito ????