O BunsenLabs (Derivativo Debian) não será desligado (falha ao iniciar o poweroff.target: a transação é destrutiva)

11

Eu me deparei com um comportamento estranho do meu BunsenLabs GNU / Linux (que é baseado no Debian).

Às vezes não consigo desligar o sistema operacional. Não importa se eu uso sudo poweroffou a abordagem da GUI.

Isto é o que recebo após a execução sudo poweroff:

Failed to start poweroff.target: Transaction is destructive

Existe uma solução alternativa? Por que isso está acontecendo?

Aqui está o conteúdo do meu /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 Mateusz Piotrowski
fonte
1
O arquivo de configuração está OK. Talvez você obtenha a melhor resposta pesquisando.
GAD3R

Respostas:

8

Estou procurando a solução há um tempo e finalmente encontrei uma solução. Funcionou para mim. Eu não sei o que desencadeia esse comportamento estranho.

Esta é a receita para desligar o seu Debian:

  1. Corra ps aux | grep suspend.

  2. Um dos resultados deve ficar assim

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

  3. Execute sudo kill 3651ou qualquer que seja o resultado do seu resultado.

  4. Na primeira vez, consegui desligar o PC. Na segunda vez que o PC foi dormir imediatamente após o killcomando.

É recomendável que você efetue logout do ambiente gráfico da área de trabalho antes de interromper o processo.

Fonte: Fóruns do Ubuntu .

Mateusz Piotrowski
fonte
6

Estou adicionando outra resposta a esta pergunta, porque no meu caso não havia nenhum systemd-sleepprocesso em execução, mas não pude parar, desligar, desligar ou reiniciar minha máquina. (Acho que esse comportamento é mais uma vez uma prova que systemdse qualifica totalmente como malware , mas vamos deixar essa discussão para outra hora.)

No final, recorri ao kernel para ajudar na minha luta contra systemd. O seguinte não é tão diferente de uma reinicialização rígida (pressionando o botão liga / desliga), mas pode ajudar, caso você não tenha acesso físico à máquina:

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

Uma vez reiniciado, prossiga pela acabando com o spawn do inferno.

Alberto Santini
fonte
1
Esta é realmente a última opção de resort. Evite se você tiver um banco de dados em execução ou boas chances de corrupção de dados. Você realmente deseja sincronizar os buffers de E / S do sistema antes de reiniciar com o echo bseguinte: echo s > /proc/sysrq-trigger(e aguarde um pouco). Então, talvez tente desmontar todos os sistemas de arquivos echo u(cuidado, este não sei se poderia fazer você perder sua conexão remota à máquina).
Totor
1
@ Motor você está certo ... no final, me vi escrevendo um script que faz tudo o que você mencionou, além de desligar alguns serviços. Foi quando percebi que basicamente o systemd me forçou a escrever meu próprio script init para desligar! Bem-vindo a 2016 ...
Alberto Santini
1

Teve esse mesmo problema. 

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

Em seguida, executei, systemctl start poweroff.target

E desligou.

Miati
fonte
não está funcionando para mim: "Falha ao iniciar o poweroff.target: a transação é destrutiva."
Ben Aveling