BunsenLabs（Debian derrivative）はシャットダウンしません（poweroff.targetの開始に失敗しました：トランザクションは破壊的です）

BunsenLabs GNU / Linux（Debianベース）の奇妙な動作に遭遇しました。

OSをオフにできないことがあります。sudo poweroffGUI を使用するかGUI を使用するかは関係ありません。

これは私が実行した後に得られるものですsudo poweroff：

Failed to start poweroff.target: Transaction is destructive

回避策はありますか？なぜそれが起こっているのですか？

これが私の内容です/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"

しばらくの間、解決策を探していましたが、最終的に解決策を見つけました。それは私のために働いた。何がこの奇妙な振る舞いを引き起こすのかはわかりません。

これは、Debianをシャットダウンするためのレシピです。

1. を実行しますps aux | grep suspend。

2. 結果の1つは次のようになります。

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

3. 実行するsudo kill 3651か、結果のpidが何であれ。

4. 初めて、PCをシャットダウンすることができました。2回目は、killコマンドの直後にPCがスリープ状態になりました。

プロセスを終了する前に、グラフィカルデスクトップ環境からログアウトすることをお勧めします。

出典：Ubuntuのフォーラム。

私の場合systemd-sleep、実行中のプロセスはなかったが、マシンを停止、シャットダウン、電源オフ、または再起動できなかったため、この質問に別の回答を追加します。（この動作はsystemd、マルウェアとして完全に適格であることをもう一度証明するものだと思いますが、その議論は別の時間に任せましょう。）

結局、私はとの闘いを助けるためにカーネルに頼りましたsystemd。以下はハードリブート（電源ボタンを押す）とそれほど変わりませんが、マシンに物理的にアクセスできない場合に役立ちます。

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

再起動したら、進んで一掃地獄の卵を。

これと同じ問題がありました。

# 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)

次に実行しました、systemctl start poweroff.target

そして、それはシャットダウンしました。