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"
systemd udev shutdown bunsenlabs Матеуш Пиотровский
источник
1
Файл конфигурации в порядке, может быть, вы получите лучший ответ при поиске.
GAD3R

Ответы:

8

Некоторое время я пытался найти решение и, наконец, нашел решение. Это сработало для меня. Я не знаю, что вызывает это странное поведение, хотя.

Это рецепт для закрытия вашего Debian:

  1. Беги ps aux | grep suspend.

  2. Один из результатов должен выглядеть так

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

  3. Беги sudo kill 3651или каков твой результат.

  4. В первый раз я смог выключить компьютер. Второй раз ПК ушел спать сразу после 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
@ То, что вы правы ... в конце концов я обнаружил, что пишу сценарий, который делает все, что вы упомянули, плюс отключение какого-либо сервиса. Именно тогда я понял, что в основном systemd заставил меня написать свой собственный скрипт инициализации для завершения работы! Добро пожаловать в 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 запустить poweroff.target

И это закрылось.

Miati
источник
не работает для меня: «Не удалось запустить poweroff.target: транзакция разрушительна».
Бен Авелинг