BunsenLabs (Debian-Derivat) wird nicht heruntergefahren (Poweroff konnte nicht gestartet werden. Ziel: Transaktion ist destruktiv)

11

Ich bin auf ein seltsames Verhalten meines BunsenLabs GNU / Linux gestoßen (das auf Debian basiert).

Manchmal kann ich das Betriebssystem nicht ausschalten. Es spielt keine Rolle, ob ich sudo poweroffden GUI-Ansatz verwende.

Das bekomme ich nach dem Laufen sudo poweroff:

Failed to start poweroff.target: Transaction is destructive

Gibt es eine Problemumgehung? Warum passiert es?

Hier ist der Inhalt von mir /lib/udev/rules.d/70-power-switch.rules:

ACTION=="remove", GOTO="power_switch_end"

SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch"
SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="thinkpad_acpi", TAG+="power-switch"

LABEL="power_switch_end"

— Mateusz Piotrowski
quelle

1

Die Konfigurationsdatei ist in Ordnung. Vielleicht erhalten Sie die beste Antwort, wenn Sie suchen.

— GAD3R

8

Ich habe eine Weile nach der Lösung gesucht und endlich eine Lösung gefunden. Es hat bei mir funktioniert. Ich weiß allerdings nicht, was dieses seltsame Verhalten auslöst.

Dies ist das Rezept zum Herunterfahren Ihres Debian:

Ausführen ps aux | grep suspend.

Eines der Ergebnisse sollte so aussehen

root 3651 0.0 0.0 8668 1716 ? Ss 07:18 0:00 /lib/systemd/systemd-sleep suspend

Run sudo kill 3651oder was auch immer die PID Ihres Ergebnisses ist.
Zum ersten Mal konnte ich den PC herunterfahren. Das zweite Mal ging der PC unmittelbar nach dem killBefehl in den Ruhezustand .

Es wird empfohlen, dass Sie sich von der grafischen Desktop-Umgebung abmelden, bevor Sie den Vorgang beenden.

Quelle: Ubuntu-Foren .

— Mateusz Piotrowski
quelle

6

Ich füge eine weitere Antwort auf diese Frage hinzu, da in meinem Fall kein systemd-sleepProzess ausgeführt wurde, ich meinen Computer jedoch nicht anhalten, herunterfahren, ausschalten oder neu starten konnte. (Ich denke, dieses Verhalten ist erneut ein Beweis dafür, dass es sich systemdvollständig als Malware qualifiziert , aber lassen wir diese Diskussion für ein anderes Mal.)

Am Ende griff ich auf den Kernel zurück, um Hilfe in meinem Kampf gegen zu erhalten systemd. Das Folgende unterscheidet sich nicht so sehr von einem Hard-Neustart (Drücken des Netzschalters), kann jedoch hilfreich sein, falls Sie keinen physischen Zugriff auf den Computer haben:

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Nach dem Neustart geht durch Auswischen der Ausgeburt der Hölle.

— Alberto Santini
quelle

1

Dies ist wirklich der letzte Ausweg. Vermeiden Sie, wenn eine Datenbank ausgeführt wird oder die Wahrscheinlichkeit einer Datenbeschädigung hoch ist. Sie möchten die E / A-Puffer des Systems wirklich synchronisieren, bevor Sie mit folgendem System neu starten echo b: echo s > /proc/sysrq-trigger(und einige Zeit warten). Versuchen Sie dann vielleicht, alle Dateisysteme mit zu mounten echo u(Vorsicht, dieses weiß ich nicht, ob Sie dadurch Ihre Remote-Verbindung zum Computer verlieren könnten).

— Totor

1

@Totor Sie haben Recht ... Am Ende habe ich ein Skript geschrieben, das alles tut, was Sie erwähnt haben, und einen Dienst heruntergefahren. Da wurde mir klar, dass systemd mich gezwungen hat, mein eigenes Init-Skript zum Herunterfahren zu schreiben! Willkommen zu 2016 ...

— Alberto Santini

1

Hatte das gleiche Problem.

# systemctl status poweroff.target 
● poweroff.target - Power-Off
  Loaded: loaded (/lib/systemd/system/poweroff.target; enabled; vendor preset: 
  Active: inactive (dead)
    Docs: man:systemd.special(7)

Ich lief dann, systemctl start poweroff.target

Und es wurde heruntergefahren.

— Miati
quelle

funktioniert bei mir nicht: "Poweroff konnte nicht gestartet werden. Ziel: Transaktion ist destruktiv."

— Ben Aveling