11

I stumbled upon a weird behaviour of my BunsenLabs GNU/Linux (which is based on Debian).

Sometimes I cannot turn off the OS. I doesn't matter whether I use sudo poweroff or the GUI approach.

This is what I get after running sudo poweroff:

Failed to start poweroff.target: Transaction is destructive

Is there a workaround? Why is it happening?

Here is the content of my /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
  • 4,623
  • 5
  • 36
  • 70

3 Answers3

8

I've been ducking for the solution for a while and finally I've found a solution. It worked for me. I don't know what triggers this weird behaviour though.

This is the recipe for shutting down your Debian:

  1. Run ps aux | grep suspend.

  2. One of the results should be looking like this

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

  3. Run sudo kill 3651 or whatever the pid of your result is.

  4. At the first time, I was able to shutdown the PC. The second time the PC went to sleep immediately after the kill command.

It is suggested that you log out of the graphical desktop environment before killing the process.

Source: Ubuntu Forums.

Mateusz Piotrowski
  • 4,623
  • 5
  • 36
  • 70
6

I am adding another answer to this question, because in my case there was no systemd-sleep process running, yet I could not halt, shutdown, poweroff, nor reboot my machine. (I think this behaviour is once more proof that systemd fully qualifies as a malware, but let's leave that discussion for another time.)

In the end, I resorted to the kernel for help in my struggle against systemd. The following is not so different from a hard-reboot (pushing the power button), but can help, in case you don't have physical access to the machine:

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

Once rebooted, proceed by wiping out the spawn of hell.

Alberto Santini
  • 160
  • 1
  • 4
  • 1
    This is really the last resort option. Avoid if you have a database running or good chances of data corruption. You really want to sync the system's IO buffers before rebooting with `echo b` like this: `echo s > /proc/sysrq-trigger` (and wait for some time). Then, maybe try to umount all filesystems with `echo u` (careful, this one I don't know if it could make you lose your remote connection to the machine). – Totor Aug 31 '16 at 21:51
  • 1
    @Totor you are right... in the end I found myself writing a script that does all you mentioned, plus shutting down some service. That's when I realised that basically systemd forced me to write my own init script to shutdown! Welcome to 2016... – Alberto Santini Sep 01 '16 at 07:41
1

Had this same issue. 

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

I then ran, systemctl start poweroff.target

And it shut down.

Miati
  • 3,080
  • 4
  • 19
  • 24