BunsenLabs (дериватив Debian) не вимкнеться (не вдалося запустити poweroff.target: транзакція руйнівна)

11

Я натрапив на дивну поведінку мого BunsenLabs GNU / Linux (в основі якого лежить Debian).

Іноді я не можу вимкнути ОС. Неважливо, я використовую sudo poweroffабо підхід 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"

— Матеуш Піотровський
джерело

1

Файл конфігурації в порядку, можливо, ви отримаєте найкращу відповідь шляхом пошуку.

— GAD3R

8

Я деякий час гнувся за рішенням і, нарешті, знайшов рішення. Це працювало для мене. Я не знаю, що викликає цю дивну поведінку.

Це рецепт вимкнення Debian:

Біжи ps aux | grep suspend.
Один з результатів повинен виглядати таким чином
```
root 3651 0.0 0.0 8668 1716 ? Ss 07:18 0:00 /lib/systemd/systemd-sleep suspend
```
Виконати sudo kill 3651або будь-який привід результату.
У перший час мені вдалося вимкнути ПК. Вдруге ПК заснув одразу після killкоманди.

Рекомендується вийти з графічного середовища робочого столу перед тим, як вбити процес.

Джерело: Форуми Ubuntu .

— Матеуш Піотровський
джерело

6

Я додаю ще одну відповідь на це запитання, оскільки в моєму випадку не було systemd-sleepзапущено жодного процесу, але я не міг ні зупинити, ні вимкнути роботу, ні перезапустити, ні перезавантажити машину. (Я думаю, що така поведінка - це ще один доказ, який systemdповністю кваліфікується як зловмисне програмне забезпечення , але давайте залишимо це обговорення на інший час.)

Врешті-решт я звернувся до ядра за допомогою у боротьбі проти systemd. Далі не так відрізняється від жорсткої перезавантаження (натискання кнопки живлення), але може допомогти, якщо у вас немає фізичного доступу до машини:

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

Після перезавантаження, продовжуйте , витираючи ікру пекла.

— Альберто Сантіні
джерело

1

Це дійсно останній варіант вдачі. Уникайте, якщо у вас працює база даних або є хороші шанси на пошкодження даних. Ви дійсно хочете синхронізувати буфери вводу-виводу системи перед перезавантаженням echo bтаким чином: echo s > /proc/sysrq-trigger(і почекати деякий час). Тоді, можливо, спробуйте придумати всі файлові системи echo u(обережно, ця, я не знаю, чи це може змусити вас втратити віддалене з'єднання з машиною).

— Тотор

1

@Totor ви маєте рацію ... врешті-решт я опинився, що пишу сценарій, який виконує все, що ви згадали, а також відключив якусь послугу. Ось тоді я зрозумів, що в основному systemd змусив мене написати власний сценарій init для відключення! Ласкаво просимо до 2016 року ...

— Альберто Сантіні

1

Був цей самий випуск.

# 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

І воно вимкнулося.

— Міаті
джерело

не працює для мене: "Не вдалося запустити poweroff.target: транзакція руйнівна."

— Бен Авелінг